Re: Is wait not interruptable?

[Peter Stephenson <pws@csr.com>]

Bart Schaefer <schaefer@brasslantern.com> wrote:
> 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?

It does work; it could probably do with being mentioned in the kill manual
entry since that specifically mentions "jobs" and "processes" at the
moment.  However, I suspect it's not quite what's wanted here, after all,
since without job control the subshells are in the same process group as
the main shell.

> } 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.

I think some rewriting may be in order... There's the vestiges of code
(trap_queue* variables in signals.c) for queueing traps (as opposed to the
current method of queueing signals, which necessarily means delaying traps,
too).  I suggest using that in this case so that signals are handled
immediately, but traps are queued except for the cases of wait or
TRAPSASYNC.  This will allow the shell to exit quickly if the signal isn't
trapped, which is the real problem in this case (and presumably the reason
for that sigdelset(set, SIGHUP) in signal_suspend_setup()).  To be clear:
nothing would change except for the handling of signals around the point
where we're doing nothing but waiting for a child.  (In particular, no
fiddling with the signal queueing code is needed.)

> } 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.

Yes, that rings a bell, now you mention it.  If traps are queued at this
point, that won't happen, at least.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php