Re: OT: Windows (Was: Re: Open Source does not mean easily

On 1/6/25 11:46, Scott Lurndal wrote:

Muttley@DastardlyHQ.org writes:

...

Unix signals should only be used to set flags that are then read later.

 
You're opinion is not widely shared.   Note that the POSIX specification
carefully notes which interfaces are not signal-safe.

What precisely does "signal-safe" mean? As I understand it, it is
supposed to be safe for a signal to interrupt standard library routines,
but that it's not safe for a signal handler to call most of those
functions. There's just a few exceptions, described below.

The C standard says the following about signal handlers:
"The functions in the standard library are not guaranteed to be
reentrant and may modify objects with static or thread storage duration.
239)" (7.1.4p4)
Footnote 239 says "Thus, a signal handler cannot, in general, call
standard library functions."

"If the signal occurs other than as the result of calling the abort or
raise function, the behavior is undefined if the signal handler refers
to any object with static or thread storage duration that is not a
lock-free atomic object and that is not declared with the constexpr
storage-class specifier other than by assigning a value to an object
declared as volatile sig_atomic_t, or the signal handler calls any
function in the standard library other than
— the abort function,
— the _Exit function,
— the quick_exit function,
— the functions in <stdatomic.h> (except where explicitly stated
otherwise) when the atomic arguments are lock-free,
— the atomic_is_lock_free function with any atomic argument, or
— the signal function with the first argument equal to the signal number
corresponding to the signal that caused the invocation of the handler.
Furthermore, if such a call to the signal function results in a SIG_ERR
return, the object designated by errno has an indeterminate
representation.310)" (7.14.1.1p5)
Footnote 310 says "If any signal is generated by an asynchronous signal
handler, the behavior is undefined."

"If a signal occurs other than as the result of calling the abort or
raise functions, the behavior is undefined if the signal handler reads
or modifies an atomic object that has an indeterminate representation."
(7.17.2p2)

"If a signal occurs other than as the result of calling the abort or
raise functions, the behavior is undefined if the signal handler calls
the atomic_init generic function." (7.17.2.1p4)

The POSIX standard claims that its version of <signal.h> conforms to the
C standard, and as far as I can see, the POSIX standard doesn't say
anything to define the behavior that is undefined by the C standard.

Could you demonstrate how, within the above restrictions, a signal
handler that doesn't cause the program to exit in one fashion or another
could do anything useful other than "set flags that are read later"?
I'm not saying it cannot be done. I claim no expertise in this kind of
programming - I never needed to write signal handlers. However, the last
time I considered the matter carefully (which was two or three versions
of the C standard ago) I couldn't figure out how to do much more than
that. At that time I did not consider how POSIX affects the issue, and I
don't know enough about POSIX signals to evaluate that issue.