Path: ...!npeer.as286.net!npeer-ng0.as286.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Geoff Clare <geoff@clare.See-My-Signature.invalid>
Newsgroups: comp.unix.programmer
Subject: Re: signal handling issues
Date: Mon, 3 Feb 2025 15:57:53 +0000
Lines: 56
Message-ID: <1l577l-gvh.ln1@ID-313840.user.individual.net>
References: <874j1g18x2.fsf@doppelsaurus.mobileactivedefense.com>
	<tBPmP.1043754$2xE6.1002585@fx18.iad>
Reply-To: netnews@gclare.org.uk
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Trace: individual.net G3KtwiCneumGZiFA8bfWrAQjQmaD4VwoKwHwf/fXdM3O8foEN8
X-Orig-Path: ID-313840.user.individual.net!not-for-mail
Cancel-Lock: sha1:UsEehx66zanx202hGIzDeDXmzoQ= sha256:gGu5bfDBKSUR8zSnPk49ulrOJg3Vp0Hu1fdB31pROZ8=
User-Agent: Pan/0.154 (Izium; 517acf4)
Bytes: 3162

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>