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
