Re: signal handling issues

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.