Path: ...!news.nobody.at!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Rainer Weikusat <rweikusat@talktalk.net>
Newsgroups: comp.unix.programmer
Subject: Re: signal handling issues
Date: Thu, 30 Jan 2025 19:11:14 +0000
Lines: 53
Message-ID: <87zfj8yv59.fsf@doppelsaurus.mobileactivedefense.com>
References: <874j1g18x2.fsf@doppelsaurus.mobileactivedefense.com>
	<tBPmP.1043754$2xE6.1002585@fx18.iad>
Mime-Version: 1.0
Content-Type: text/plain
X-Trace: individual.net BbOUrmobmc9EcCztuhuImgeTQ12tacmQnKh8tzfDOPX7/NIc4=
Cancel-Lock: sha1:isgoVJeA0ty79knlmUo8SKvmqgk= sha1:S13oLecd92REZk+p30eE2EJD8Uo= sha256:5JVpNfeD2BiqiGDH3ygrJ0ypHNW3N9nhcTBQsqZ+AMI=
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
Bytes: 2860

scott@slp53.sl.home (Scott Lurndal) writes:
> 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:
>>
>>----

[example program removed]

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

[signal being synchronously raised

.... otherwise, behaviour always undefined if handler calls any unsafe
function regardless of the older requirement quoted above]

[...]

> once multithreading was introduced, the stdio library functions were
> required to synchronize access to the underlying FILE buffers between
> threads.  As those are library functions which invoke kernel system
> calls, unless they mask signals, they can be interrupted while they
> own exclusive access to the stream.
>
> Subsequent accesses from a signal handler to that stream
> will block indefinitely.

These functions were never async-signal-safe and I don't quite
understand why this locking would necessarily conflict with the
requirement that unsafe functions shall behave as documented when called
from a signal handler or interrupted by a signal unless the signal
handler interrupted an unsafe function and also called an unsafe
function.

For stdio, this basically just means that a stream used by some stdio
routine must be unlocked by the time it returns to its caller.