tihor@acf4.UUCP (Stephen Tihor) (07/25/86)
A novice question I am afraid. Under BSD 4.2 a friend wrote a little infinite sleep loop with a signal handler that displays the signal number. His testing with kill implies that the ALARM signal does interupt the sleep but doesn't invoke the handler. But he swears up and down that he set the handler for that (He looped to set all the handlers.)
chris@umcp-cs.UUCP (Chris Torek) (07/26/86)
In article <9250003@acf4.UUCP> tihor@acf4.UUCP (Stephen Tihor) writes: >... a friend wrote a little infinite sleep loop with a signal handler >that displays the signal number. His testing with kill implies that >the ALARM signal does interupt the sleep but doesn't invoke the handler. This is indeed the case. To see why, you must first know that there is no sleep `system call'. There once was such a call, I understand; but it was replaced with alarm(). alarm() is more general than sleep(), for it can alert you some time in the future, whether or not you are doing anything. To sleep, all you need do is ask to be alerted, then do nothing: /* * Simplified `sleep' routine. */ sleep(seconds) int seconds; { int wake_me_up(); signal(SIGALRM, wake_me_up); alarm(seconds); /* set the alarm clock */ sigpause(0); /* then take a nap */ } wake_me_up() { /* do nothing: sigpause returns after any signal occurs. */ } sleep() is actually horridly complex, to account for possible pending alarms, other signal handlers, and so forth; and due to signal vagaries, only the versions in 4.2 and 4.3 BSD can be written reliably (and as I recall, the distributed 4.2 version was buggy anyway!). But the basic idea is that simple: set the alarm and wait for it to go off. If you use `kill -ALRM', sleep thinks that alarm signal is its own, and returns. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
khasin@hcrvx2.UUCP (Khasin Teow) (07/28/86)
In article <9250003@acf4.UUCP> tihor@acf4.UUCP (Stephen Tihor) writes: >A novice question I am afraid. Under BSD 4.2 a friend wrote a little >infinite sleep loop with a signal handler that displays the signal number. >His testing with kill implies that the ALARM signal does interupt the >sleep but doesn't invoke the handler. But he swears up and down that he set >the handler for that (He looped to set all the handlers.) If my assumption is correct in that the "infinite sleep loop" involves the sleep(3) call, then his SIGALRM handler will not be invoked when SIGALRM is received since that handler has already been replaced by the SIGALRM handler in the sleep subroutine. At least this is true on System V.2. Kha Sin TEOW @ HCR