Re: signals generated ONLY by abort, kill, or raise

From: Kurtis D. Rader (krader@skepticism.us)
Date: 04/23/03 

From: "Kurtis D. Rader" <krader@skepticism.us>
Date: Tue, 22 Apr 2003 21:46:41 -0700

On Tue, 22 Apr 2003 13:57:52 +0000, Marc Rochkind wrote:

> According to the SUS, if a signal handler was called because the signal
> was generated by abort, kill, or raise, certain restrictions are lifted
> (e.g., what storage can be modified). The issue then becomes, how do you
> KNOW that the signal was generated by abort, kill, or raise?
>
> It seems to me that there are only four portable signals that can ONLY be
> generated by abort, kill, or raise: SIGABRT, SIGTERM, SIGUSR1, and
> SIGUSR2.

I believe the passage you cite is attempting to differentiate between
signals sent synchronously by the process to itself versus asynchronously
delivered signals. The problem is that any signal can be sent
asynchronously. Just because SIGABRT, for example, is intended to be used
by the abort() function does not preclude it being delivered asynchronously
to the execution of the process due to some external event (e.g., a user
typing "kill -ABRT $pid").

A signal sent by the process to itself is synchronous in that it is
guaranteed to be delivered immediately if not otherwise blocked or ignored.
Which means that the signal handler can, in theory, do things that would
otherwise be unsafe since it knows the context of the process when the
signal was delivered.

> Am I right about these four? Are there any other portable signals I've
> missed? (I'm a little concerned by exotic terminal drivers, perhaps not
> yet invented, that might allow a user to associate any signal with any
> control key.)
>
> Also, shouldn't the SUS have included pthread_kill along with abort,
> kill, and raise?

Threads obviously complicate matters since it is no longer sufficient to
simply detect whether the signal was sent by your pid calling kill(). You
now have to worry if the thread handling the signal is the thread that
generated it. Note that in the absence of threads it should be sufficient
to check the sending pid from the siginfo or sigcontext structure to the
value returned by getpid(). If they're the same then the set of safe
functions is increased.

Relevant Pages