Re: Is wait not interruptable?

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Dec 17,  4:00pm, Peter Stephenson wrote:
}
} I see the external command kill on Linux allows you to send a signal to
} a process group, but I don't think there's a way of doing that within
} zsh.

Sure there is.  The negative PID thing is implemented at the OS level by
the kill(2) system call, so "kill -HUP -12345" even from the zsh builtin
will kill the entire process group of 12345.  Or at least it's intended
to do so -- has something changed such that zsh's kill won't handle a
negative PID any more?

} I wondered if it was because receiving the "wrong" signal when waiting
} for SIGCHLD would confuse the shell logic.  But the loops surrounding
} both calls to signal_suspend() seem to contradict that.
} 
} Surely the right thing to do would be to use a more lenient signal mask
} in signal_suspend(), since we know that's a good place for signal
} handling---although we might have to queue traps for later execution
} unless one of TRAPSASYNC or the wait builtin is in use.

This may be an artifact from before trap queuing was possible, then.  I
generally concur with your assessment here.

} So is the delayed execution of traps the only issue?  What have I
} missed?  Signal handlers theselves don't need to guard against recursive
} calling, do they?

The handler functions themselves don't, no, unless (IIRC) the handler is
explicitly reset from within the function.  Which could happen if the
handler calls a shell function which calls "trap", I suppose.