Re: signal handling issues

Liste des GroupesRevenir à cu programmer 
Sujet : Re: signal handling issues
De : geoff (at) *nospam* clare.See-My-Signature.invalid (Geoff Clare)
Groupes : comp.unix.programmer
Date : 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=66

It 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>

Date Sujet#  Auteur
30 Jan 25 * signal handling issues14Rainer Weikusat
30 Jan 25 +- Re: signal handling issues1Rainer Weikusat
30 Jan 25 +* Re: signal handling issues4Kaz Kylheku
30 Jan 25 i`* Re: signal handling issues3Dan Cross
31 Jan 25 i `* Re: signal handling issues2Rainer Weikusat
31 Jan 25 i  `- Re: signal handling issues1Dan Cross
30 Jan 25 +* Re: signal handling issues5Kaz Kylheku
31 Jan 25 i`* Re: signal handling issues4Muttley
1 Feb 25 i `* Re: signal handling issues3Lawrence D'Oliveiro
2 Feb 25 i  `* Re: signal handling issues2Muttley
4 Feb 25 i   `- Re: signal handling issues1Rainer Weikusat
3 Feb 25 `* Re: signal handling issues3Geoff Clare
6 Feb 25  `* Re: signal handling issues2Geoff Clare
6 Feb 25   `- Re: signal handling issues1Rainer Weikusat

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal