Re: signal handling issues

On 2025-01-30, Scott Lurndal <scott@slp53.sl.home> wrote:

Rainer Weikusat <rweikusat@talktalk.net> writes:

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, the stdio library functions
were required to synchronize access to the underlying
FILE buffers between threads.

But the requirement applies to a single-threaded program in
which an asynchronous signal occurs.

The multi-threaded case seems to say that if the program is MT,
then if a signal occurs even as a result of the program
calling raise, etc, it is effectivecly an async signal
(since it happens as the result of a thread executing
asynchronously with regard to whatever thread catches the signal
via a handler.)

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.

But those functions were never dubbed async safe; the first requirement
quoted by Rainer from Issue 6 already makes it undefined to call putc
from a signal handler interrupting putc.

That covers all situations in which the interrupt would observe
stdio to be in any kind of bad state, including holding a mutex.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca