From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17611 invoked from network); 18 Dec 2006 16:53:19 -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 16:53:19 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 17208 invoked from network); 18 Dec 2006 16:53:10 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 18 Dec 2006 16:53:10 -0000 Received: (qmail 20108 invoked by alias); 18 Dec 2006 16:53:08 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 23069 Received: (qmail 20099 invoked from network); 18 Dec 2006 16:53:08 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 18 Dec 2006 16:53:08 -0000 Received: (qmail 16935 invoked from network); 18 Dec 2006 16:53:08 -0000 Received: from cluster-c.mailcontrol.com (168.143.177.190) by a.mx.sunsite.dk with SMTP; 18 Dec 2006 16:53:04 -0000 Received: from cameurexb01.EUROPE.ROOT.PRI ([62.189.241.200]) by rly20c.srv.mailcontrol.com (MailControl) with ESMTP id kBIGpHs5020834 for ; Mon, 18 Dec 2006 16:52:47 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 16:51:34 +0000 Received: from news01.csr.com (localhost.localdomain [127.0.0.1]) by news01.csr.com (8.13.8/8.13.4) with ESMTP id kBIGpRQY018515 for ; Mon, 18 Dec 2006 16:51:27 GMT Received: from csr.com (pws@localhost) by news01.csr.com (8.13.8/8.13.8/Submit) with ESMTP id kBIGpRa5018512 for ; Mon, 18 Dec 2006 16:51:27 GMT Message-Id: <200612181651.kBIGpRa5018512@news01.csr.com> X-Authentication-Warning: news01.csr.com: pws owned process doing -bs To: Zsh hackers list Subject: Re: Is wait not interruptable? In-reply-to: <061218083717.ZM3869@torch.brasslantern.com> References: <200612171600.kBHG0IXv005533@pwslaptop.csr.com> <061217095424.ZM2103@torch.brasslantern.com> <20061218113953.c19237da.pws@csr.com> <20061218161229.7bbec427.pws@csr.com> <061218083717.ZM3869@torch.brasslantern.com> Comments: In-reply-to Bart Schaefer message dated "Mon, 18 Dec 2006 08:37:17 -0800." Date: Mon, 18 Dec 2006 16:51:26 +0000 From: Peter Stephenson X-OriginalArrivalTime: 18 Dec 2006 16:51:34.0147 (UTC) FILETIME=[C66F5D30:01C722C4] Content-Type: text/plain MIME-Version: 1.0 X-Scanned-By: MailControl A-07-06-00 (www.mailcontrol.com) on 10.67.0.130 Bart Schaefer wrote: > Note that the important thing through this whole section is that > last_signal is sane, so that we don't end up waiting for the wrong > child if both a SIGCHLD and some other signal arrive during the > signal_suspend(). (I may be missing a detail that makes that comment > irrelevant.) I don't think there should be a problem with signal ordering. It's not affected by the changes to traps --- none of the code I touched affects last_signal, except, obviously, the fact that we may now handle some signals earlier; but we had to be prepared to handle signals at that point anyway. > } One slight difference is that in zwaitjob() we'll delay traps to wait > } for the entire foreground job, not just the first process to exit. > > Is that affected by TRAPS_ASYNC? Yes, if TRAPS_ASYNC is set (or we're at the wait builtin) we'd have handled the trap already. The difference is only if we'd otherwise have been delaying signal delivery. -- 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