Broken alarm(3)

[John Reiser]

> I don't know when, but the alarm system call no longer works
> properly.  The following program works on Unix but not
> Linux FC4t3 or FC3.  This is the mechanism rz/sz use for 
> generating protocol timeouts.

 From the kernel's viewpoint, the signal handler never returns.
The kernel has no knowledge of the longjmp().
So, the kernel is still blocking the delivery of SIGALRM, the signal
which caused entry into the first handler.  This is BSD semantics.

"man signal" says:
        The original Unix signal() would reset the handler to SIG_DFL, and Sys-
        tem  V  (and the Linux kernel and libc4,5) does the same.  On the other
        hand, BSD does not reset the handler, but blocks new instances of  this
        signal from occurring during a call of the handler.  The glibc2 library
        follows the BSD behaviour.

The program works the same way for me (alarm happens once, signal is caught,
handler performs longjmp() out of handler, message is printed, signal is
re-armed, alarm() is called, read() is restarted, alarm never happens)
on each of these systems:
   RedHat 7.3  kernel 2.4.18-10         glibc 2.2.5-39       Apr. 2002
   RedHat 8.0  kernel 2.4.18-24.8.0     glibc 2.2.93-5       Sept. 2002
   RedHat 9    kernel 2.4.20-2.9        glibc 2.3.2-11.9     Feb. 2003
   FC3         kernel 2.6.10-1.766_FC3  glibc 2.3.5-0.fc3.1  Feb. 2005

Recommendation: use setitimer(), sigaction(), and do not longjmp() out of
a signal handler.

--