tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: patch adding a pidfile-option to script(1)
>>> 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 mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Home |
Main Index |
Thread Index |
Old Index