From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28094 invoked from network); 17 Dec 2006 17:54:55 -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.5 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; 17 Dec 2006 17:54:55 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 88889 invoked from network); 17 Dec 2006 17:54:48 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 17 Dec 2006 17:54:48 -0000 Received: (qmail 13023 invoked by alias); 17 Dec 2006 17:54:46 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 23062 Received: (qmail 13014 invoked from network); 17 Dec 2006 17:54:45 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 17 Dec 2006 17:54:45 -0000 Received: (qmail 88535 invoked from network); 17 Dec 2006 17:54:45 -0000 Received: from vms044pub.verizon.net (206.46.252.44) by a.mx.sunsite.dk with SMTP; 17 Dec 2006 17:54:42 -0000 Received: from torch.brasslantern.com ([71.116.86.88]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JAF00L6NJ2R73LA@vms044.mailsrvcs.net> for zsh-workers@sunsite.dk; Sun, 17 Dec 2006 11:54:30 -0600 (CST) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id kBHHsPEx002105 for ; Sun, 17 Dec 2006 09:54:26 -0800 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id kBHHsOT0002104 for zsh-workers@sunsite.dk; Sun, 17 Dec 2006 09:54:24 -0800 Date: Sun, 17 Dec 2006 09:54:24 -0800 From: Bart Schaefer Subject: Re: Is wait not interruptable? In-reply-to: <200612171600.kBHG0IXv005533@pwslaptop.csr.com> To: Zsh hackers list Message-id: <061217095424.ZM2103@torch.brasslantern.com> MIME-version: 1.0 X-Mailer: OpenZMail Classic (0.9.2 24April2005) Content-type: text/plain; charset=us-ascii References: <200612171600.kBHG0IXv005533@pwslaptop.csr.com> Comments: In reply to Peter Stephenson "Re: Is wait not interruptable?" (Dec 17, 4:00pm) 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.