Path: ...!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.unix.programmer
Subject: Re: OT: Windows (Was: Re: Open Source does not mean easily
Date: Mon, 6 Jan 2025 18:16:31 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vlh6lv$op9$1@reader2.panix.com>
References: <uu54la$3su5b$6@dont-email.me> <vlgud7$1mgh5$1@dont-email.me> <4OTeP.44026$vfee.5216@fx45.iad> <vlh4mo$1nccc$1@dont-email.me>
Injection-Date: Mon, 6 Jan 2025 18:16:31 -0000 (UTC)
Injection-Info: reader2.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="25385"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Bytes: 4458
Lines: 89

In article <vlh4mo$1nccc$1@dont-email.me>,
James Kuyper  <jameskuyper@alumni.caltech.edu> wrote:
>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.

From POSIX 2024, sectino 2.4 ("Signal Concepts"):

|The following table defines a set of functions and
|function-like macros that shall be async-signal-safe.
|Therefore, applications can call them, without restriction,
|from signal-catching functions.  Note that, although there is
|no restriction on the calls themselves, for certain functions
|there are restrictions on subsequent behavior after the
|function is called from a signal-catching function (see longjmp()).
(https://pubs.opengroup.org/onlinepubs/9799919799/functions/V2_chap02.html#tag_16_04)

(The table mentioned above includes over 200 functions.)

>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."

This is comp.unix.programmer, not comp.lang.c.

>[snip]
>
>"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.

This is factually incorrect.

>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"?

Those restrictions don't apply in this context.  But a trivial
example:

    void
    reaper(int signo)
    {
        (void)signo;
        wait(NULL);
    }


    /* ... */
    signal(SIGCHLD, reaper);

>I'm not saying it cannot be done. I claim no expertise in this kind of
>programming - I never needed to write signal handlers.

Perhaps read up on the matter before commenting, then?

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

In strict C, this is correct.  But while POSIX includes ISO C as
a subset, it extends allowable behavior in lots of places to
both standardize the behavior of existing programs as well as
make it possible to write useful programs on Unix-style systems.

	- Dan C.