Gavin Lambert wrote: > While I admit to being mostly ignorant of signals (I don't really use them): > aren't signal handlers set by signal() single-shot handlers? So if a second > signal arrives before the signal handler itself calls signal() again then > it'll get default processing, which might be to abort
It's worth reading "man 2 signal": The behavior of signal varies across Unix versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. The original Unix signal() would reset the handler to SIG_DFL, and System 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 behavior. If one on a libc5 system includes <bsd/signal.h> instead of <signal.h> then signal() is redefined as __bsd_signal() and signal() has the BSD semantics. This is not recommended. If one on a glibc2 system defines a feature test macro such as _XOPEN_SOURCE or uses a separate sysv_signal(3) function, one obtains classical behavior. This is not recommended. On modern Linux, signal() handlers are _not_ single-shot, unless you have particular compile-time settings, or use a different C library. To be sure you should always use sigaction(). That's the POSIX standard function, and widespread. -- Jamie _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev