Zsh Mailing List Archive
Messages sorted by:
Re: Is wait not interruptable?
- X-seq: zsh-workers 23062
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Zsh hackers list <zsh-workers@xxxxxxxxxx>
- Subject: Re: Is wait not interruptable?
- Date: Sun, 17 Dec 2006 09:54:24 -0800
- In-reply-to: <200612171600.kBHG0IXv005533@xxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <200612171600.kBHG0IXv005533@xxxxxxxxxxxxxxxxx>
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
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.
Messages sorted by: