Re: Is wait not interruptable?

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Dec 18,  4:12pm, Peter Stephenson wrote:
}
} As I noted in a comment, there's presumably a race when queuing traps since
} the signal may already have been delivered by the time we start the trap
} queuing.  That's not new (we only queue traps at roughly the point where we
} previously blocked signals).  I could move the new queue_traps() before
} dont_queue_signals() in the two applicable functions: then traps would be
} queued when the previously blocked signals arrive.

As long as it's "safe" (in terms of shell function re-entrancy) and not
semantically incorrect for traps to be executed at that point, I think
what you have is fine.

Note that the important thing through this whole section is that
last_signal is sane, so that we don't end up waiting for the wrong
child if both a SIGCHLD and some other signal arrive during the
signal_suspend().  (I may be missing a detail that makes that comment
irrelevant.)

} One slight difference is that in zwaitjob() we'll delay traps to wait
} for the entire foreground job, not just the first process to exit.

Is that affected by TRAPS_ASYNC?