From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6306 invoked from network); 18 Dec 2006 11:42:09 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 18 Dec 2006 11:42:09 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 76560 invoked from network); 18 Dec 2006 11:42:03 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 18 Dec 2006 11:42:03 -0000 Received: (qmail 6141 invoked by alias); 18 Dec 2006 11:41:51 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 23063 Received: (qmail 6130 invoked from network); 18 Dec 2006 11:41:50 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 18 Dec 2006 11:41:50 -0000 Received: (qmail 76289 invoked from network); 18 Dec 2006 11:41:49 -0000 Received: from cluster-d.mailcontrol.com (217.69.20.190) by a.mx.sunsite.dk with SMTP; 18 Dec 2006 11:41:46 -0000 Received: from cameurexb01.EUROPE.ROOT.PRI ([62.189.241.200]) by rly13d.srv.mailcontrol.com (MailControl) with ESMTP id kBIBdawh006278 for ; Mon, 18 Dec 2006 11:41:32 GMT Received: from news01.csr.com ([10.103.143.38]) by cameurexb01.EUROPE.ROOT.PRI with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Dec 2006 11:39:59 +0000 Date: Mon, 18 Dec 2006 11:39:53 +0000 From: Peter Stephenson To: Zsh hackers list Subject: Re: Is wait not interruptable? Message-Id: <20061218113953.c19237da.pws@csr.com> In-Reply-To: <061217095424.ZM2103@torch.brasslantern.com> References: <200612171600.kBHG0IXv005533@pwslaptop.csr.com> <061217095424.ZM2103@torch.brasslantern.com> Organization: Cambridge Silicon Radio X-Mailer: Sylpheed version 2.2.10 (GTK+ 2.10.4; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Dec 2006 11:39:59.0441 (UTC) FILETIME=[3F859C10:01C72299] X-Scanned-By: MailControl A-07-06-00 (www.mailcontrol.com) on 10.68.0.123 Bart Schaefer 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 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