[uClinux-dev] MCF5249 GPIO5/SIGILL Interrupt Crash

[Jamie Lokier]

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