> Date: Wed, 16 Sep 2026 23:18:26 -0400 (EDT) > From: Mouse <[email protected]> > > >>> This patch can be made safe with a much smaller modification: > >>> simply keep SIGUSR1 blocked _except_ during the calls to read() and > >>> write() in dooutput(), when there is no risk of interrupting access > >>> to the stdio data structures. > >> That makes it safe...for one particular implementation. It is not > >> safe in general. There is no promise that stdio is signal-unsafe > >> only when the signal interrupts a stdio call, though that is the way > >> most implementations happen to work. > > > No, it is safe in general for all POSIX-conformant systems: > > > [...] > > Yes and no. > > That particular change - blocking the signal except during > read()/write() - is safe. But the "when there is no risk of > interrupting access to the stdio data structures" is misleading; while > it is mostly about that under NetBSD, to be safe in theory you have to > guard against all signal-unsafe functions, not just those that poke at > stdio data structures. (And, indeed, if the call done in the signal > handler is one that can cause stdio to malloc, even in practice you > have to guard against interrupting malloc-family calls too even though > they have nothing to do with stdio's data structures.)
You are technically correct that -- depending on the definition of `the stdio data structures' -- the informal explanation I gave might not be perfectly sufficient to justify the safety of the specific change I suggested. And that rephrasing the explanation as `when there is no risk of interrupting any function that is not formally marked as async-signal-safe in IEEE Std. 1003.1-2024, Volume XSH: System Interfaces, Sec. 2.4.3 ``Signal Actions'' ' instead would justify the safety of the specific change I suggested. (Meanwhile the rest of the change turns out to be troublesome for other reasons because the file is open in two separate processes, so I don't think this subthread needs any further litigation!)
