Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Rainer Weikusat Newsgroups: comp.unix.programmer Subject: Re: OT: Windows (Was: Re: Open Source does not mean easily Date: Mon, 06 Jan 2025 18:24:24 +0000 Lines: 53 Message-ID: <87wmf7g5rb.fsf@doppelsaurus.mobileactivedefense.com> References: <1jSeP.17355$jUJ9.3923@fx08.iad> <4OTeP.44026$vfee.5216@fx45.iad> Mime-Version: 1.0 Content-Type: text/plain X-Trace: individual.net zPzQn4b8c6H83soEbGjB7gKMvRG5mgFa/ppoOJncMqRh2tvn4= Cancel-Lock: sha1:nGn2A+Tvmq7PBCpP6vThm7noG/g= sha1:FqWXyLkOTa6yBANpKDPihLzMOHk= sha256:1ar3ZNRWJAKFPBG0R2Zq0UoKtIs5u514OrQtnI8EuA4= User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) Xref: csiph.com comp.unix.programmer:16859 James Kuyper writes: > 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? The UNIX standard has meanwhile started to contradict itself on this topic because of the apparent attempt to follow the (pretty silly) C++ memory model incorporated into C for no particular reason. But the relevant part of the UNIX definition (still part of the current definition) used to be In the presence of signals, all functions defined by this volume of POSIX.1-2024 shall behave as defined when called from or interrupted by a signal-catching function, with the exception that when a signal interrupts an unsafe function or function-like macro, or equivalent (such as the processing equivalent to exit() performed after a return from the initial call to main()), and the signal-catching function calls an unsafe function or function-like macro, the behavior is undefined. This text is below the list of async-signal safe interfaces. It contradicts the the behavior is undefined if: [...] The signal handler calls any function or function-like macro defined in this standard other than one of the functions and macros specified below as being async-signal-safe. immediately above it. https://pubs.opengroup.org/onlinepubs/9799919799/functions/V2_chap02.html#tag_16_04 When ignoring the apparent attempt at making signals really impossible to use, "async signal-safe" is really quite simple: Any handler can do anything provided it doesn't invoke some kind of not async signal safe interface. A handler which didn't interrupt an interface that's not async signal safe can anything, including calling unsafe functions. A usual way to achieve the latter is to keep signals blocked except when calling an async signal safe functions, eg, pselect, ppoll or sigsuspend.