🚀 go-pugleaf

In article <225@jetson.UPMA.MD.US>, john@jetson.UPMA.MD.US (John Owens) writes:
< In article <1232@netcom.UUCP>, chris@netcom.UUCP (Chris Lakewood) writes:
< > ]	alarm(n);
< > ]	pause();
< > ](the guts of sleep) and what happens if the process doesn't run for n
< 
< > Don't leave us in suspense...  What happens if the process doesn't run for
< > n seconds?  Actually, the process won't run for at least n seconds unless
< > it receives some signal.  The pause causes the process to block until a
< > signal is received.
< 
< If the process doesn't run for 'n' seconds *after* the alarm() is
< posted and *before* pause() is called, it'll get a SIGALRM (which is,
< I think, set to SIG_IGN at that point), not do anything, then call
< pause() too late....

There's a way to get around this, so that if more than n seconds elapse
since the calling of alarm(n) before the system gets around to calling
pause(), sleep() will still return.  This is left as an exercise to the
reader.  Anyone with System V Release 2 source code (and possibly earlier, I
don't have it on hand to check) can see for themselves how this is done.

Someone mentioned making sleep() a true system call.  I can see good reasons
for this.  (One reason is to get around the fact that the sleep() code work
around has critical sections, where other signal handlers being invoked at
just the right [wrong?] place within it and doing certain things might cause
a stack botch or other anomalous behavior.)

But guaranteeing that sleep() will not hang forever on a slow system is not it.
-- 
Dan'l Levy                 UNIX(R) mail:  att!ttbcad!levy, att!cbnewsc!danl
AT&T Bell Laboratories
5555 West Touhy Avenue     Any opinions expressed in the message above are
Skokie, Illinois  60077    mine, and not necessarily AT&T's.