From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18150 invoked from network); 16 May 2005 10:46:58 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 16 May 2005 10:46:58 -0000 Received: (qmail 51410 invoked from network); 16 May 2005 10:46:53 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 16 May 2005 10:46:53 -0000 Received: (qmail 9712 invoked by alias); 16 May 2005 10:46:50 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 21262 Received: (qmail 9702 invoked from network); 16 May 2005 10:46:50 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 16 May 2005 10:46:50 -0000 Received: (qmail 51105 invoked from network); 16 May 2005 10:46:50 -0000 Received: from mailhost1.csr.com (HELO MAILSWEEPER01.csr.com) (81.105.217.43) by a.mx.sunsite.dk with SMTP; 16 May 2005 10:46:45 -0000 Received: from exchange03.csr.com (unverified [10.100.137.60]) by MAILSWEEPER01.csr.com (Content Technologies SMTPRS 4.3.12) with ESMTP id for ; Mon, 16 May 2005 11:44:58 +0100 Received: from news01.csr.com ([10.103.143.38]) by exchange03.csr.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 16 May 2005 11:48:03 +0100 Received: from news01.csr.com (localhost.localdomain [127.0.0.1]) by news01.csr.com (8.13.1/8.12.11) with ESMTP id j4GAknx2018206 for ; Mon, 16 May 2005 11:46:49 +0100 Received: from csr.com (pws@localhost) by news01.csr.com (8.13.1/8.13.1/Submit) with ESMTP id j4GAknfO018203 for ; Mon, 16 May 2005 11:46:49 +0100 Message-Id: <200505161046.j4GAknfO018203@news01.csr.com> X-Authentication-Warning: news01.csr.com: pws owned process doing -bs To: zsh-workers@sunsite.dk Subject: Re: localtraps and signal handling on NetBSD In-reply-to: <20050514043338.GA82132@quark.hightek.org> References: <20050425063521.GA17598@quark.hightek.org> <1050425163202.ZM25027@candle.brasslantern.com> <20050426030308.GA21501@quark.hightek.org> <200504261834.j3QIYHSa018951@news01.csr.com> <1050427053638.ZM28743@candle.brasslantern.com> <200504270954.j3R9sujP029445@news01.csr.com> <20050507171938.GA51740@quark.hightek.org> <5415.1115631148@csr.com> <20050510184600.GA67763@quark.hightek.org> <200505131127.j4DBR0Yt014380@news01.csr.com> <20050514043338.GA82132@quark.hightek.org> Date: Mon, 16 May 2005 11:46:49 +0100 From: Peter Stephenson X-OriginalArrivalTime: 16 May 2005 10:48:03.0850 (UTC) FILETIME=[BC7B66A0:01C55A04] X-Spam-Checker-Version: SpamAssassin 3.0.2 on a.mx.sunsite.dk X-Spam-Level: X-Spam-Status: No, score=-2.6 required=6.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Hits: -2.6 Vincent Stemen wrote: > # --------- ----------- > sigterm1() > { > trap 'echo "-- sigterm2 --"' TERM > echo "sigterm1(): sending SIGTERM" > kill -TERM $$ > trap sigterm1 TERM > sleep 1 > } > > trap sigterm1 TERM > > echo > echo "main: sending SIGTERM" > kill -TERM $$ > echo "main: sending SIGTERM" > kill -TERM $$ > # --------- ----------- > > Here is the output of zsh and bash. > > > main: sending SIGTERM > sigterm1(): sending SIGTERM > sigterm1(): sending SIGTERM > sigterm1(): sending SIGTERM > sigterm1(): sending SIGTERM > ... continues forever > Yes, I can see this, but this isn't the same example I was looking at when I saw different behaviour from you. What I think is happening here is that signals *are* being queued. Then the SIGTERM is delivered after sigterm1 has returned, at which point sigterm1 has been reinstalled as the signal handler, so gets called again ad infinitum. In this case bash and zsh are actually trying a bit harder to do the right thing, at least as far as safety of the execution environment is concerned. Not queueing signals can cause significant reentrancy problems. However, it may be possible to unqueue signals temporarily at some point. That's still not trivial; the code's currently not written to allow that, since as I said before the queue/unqueues are all nested and you need to have some clue about the environment to decide whether temporarily unqueuing is safe. Possibly some queue/unqueue pair can be moved deeper into the code, leaving some points at which signals will be handled, but that's not trivial either. -- Peter Stephenson Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. **********************************************************************