Xref: utzoo comp.unix.internals:1965 comp.unix.wizards:23969
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!rbj
From: rbj@uunet.UU.NET (Root Boy Jim)
Newsgroups: comp.unix.internals,comp.unix.wizards
Subject: Re: BSD vs. Sys V alarm and SIGALRM PROBLEMS!
Keywords: A Bug or not a Bug?
Message-ID: <121464@uunet.UU.NET>
Date: 5 Feb 91 19:08:16 GMT
References: <3313@lamont.ldgo.columbia.edu>
Followup-To: comp.unix.internals
Organization: UUNET Communications Services, Falls Church, VA
Lines: 33

In article <3313@lamont.ldgo.columbia.edu> cats@lamont.ldgo.columbia.edu (catherine susch) writes:
>
>
>	We believe that we've discovered a problem/bug with 
>	the alarm(3) function and signal(2). Give us your 
>	feedback if you	think otherwise, because we think 
>	that this is a major problem that needs fixing. 

What you have discovered is an incompatibility between systems.
There are two kinds of system calls. Ones that are interruptible,
and ones that aren't. Most are not. Wait and read or write on a
slow device (such as a tty, where input may never occur) are
interruptible. When interrupted by a signal handler, they
return -1 and set errno to EINTR, or EAGAIN or some such.

Berkeley changed these calls to automaticly restart in 4.2BSD.
Purists screamed long and hard and a bit was put into the sigvec
to allow a choice to be made for each type of signal.

I don't know which versions you have. Another complication is
that you are using two timeouts, not one. Probably the most
portable solution is to use setjmp with the getchar and
longjmp from the alarm routine.

You are right. It is a major problem. It has been fixed, in the
POSIX specs, but it'll take awhile until everyone is fully
compliant. Also, POSIX doesn't specify the behavior of "signal",
only that of "sigaction". Such is life.
-- 

	Root Boy Jim Cottrell <rbj@uunet.uu.net>
	I got a head full of ideas
	They're driving me insane