>>> 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.) I'm particularly aware of malloc because one of my jobs has run into trouble because of a program that does *far* too much inside signal handlers and has been giving trouble due to malloc-family calls being interrupted. But I'm sure there are other subsystems which are equally capable of causing trouble. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
