Sujet : Re: signal handling issues
De : geoff (at) *nospam* clare.See-My-Signature.invalid (Geoff Clare)
Groupes : comp.unix.programmerDate : 03. Feb 2025, 16:57:53
Autres entêtes
Message-ID : <1l577l-gvh.ln1@ID-313840.user.individual.net>
References : 1 2
User-Agent : Pan/0.154 (Izium; 517acf4)
Scott Lurndal wrote:
Rainer Weikusat <rweikusat@talktalk.net> writes:
Up to and including The Open Group Base Specifications Issue 6, the
following program was a correct way of using signal handlers:
>
>
As the only requirement for functions not listed as async-signal-safe
was
>
In the presence of signals, all functions defined by this volume
of IEEE Std 1003.1-2001 shall behave as defined when called from
or interrupted by a signal-catching function, with a single
exception: when a signal interrupts an unsafe function and the
signal-catching function calls an unsafe function, the behavior
is undefined.
>
Since version 7, its behaviour is undefined because the following
requirement was added:
>
If the process is multi-threaded, or if the process is
single-threaded and a signal handler is executed other than as
the result of:
While Geoff may chime in with the definitive answer, once
multithreading was introduced, [...]
Although multithreading complicates things, it wasn't the reason for
this change. After some digging I found the source of the change,
which was this bug:
https://austingroupbugs.net/view.php?id=66It updated some text on the signal() page and then copied it into
XSH 2.4.3.
So the conflict Rainer has identified was already there in Issue 6,
but only for signal handlers installed using signal(), not sigaction().
Obviously it made no sense for there to be different signal handler
rules depending on which function installed the handler, hence the
copying.
The underlying cause of the problem is the need to match the signal
handling rules in the C standard (C99 at the time), but with the
concept of async-signal-safe functions incorporated. It appears that
mostly this was done from the point of view of what can be safely done
in a signal handler that could be called at any time. The other aspect,
of the case when the signal only ever interrupts async-signal-safe
functions, was never fully realised.
I think the first paragraph quoted by Rainer above shows the intention,
but it was not properly allowed for in the text on the signal() page
that was copied to XSH 2.4.3.
-- Geoff Clare <netnews@gclare.org.uk>