From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14906 invoked from network); 13 May 2005 11:27:23 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 13 May 2005 11:27:23 -0000 Received: (qmail 60590 invoked from network); 13 May 2005 11:27:17 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 13 May 2005 11:27:17 -0000 Received: (qmail 2591 invoked by alias); 13 May 2005 11:27:14 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 21258 Received: (qmail 2575 invoked from network); 13 May 2005 11:27:14 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 13 May 2005 11:27:14 -0000 Received: (qmail 60265 invoked from network); 13 May 2005 11:27:14 -0000 Received: from mailhost1.csr.com (HELO MAILSWEEPER01.csr.com) (81.105.217.43) by a.mx.sunsite.dk with SMTP; 13 May 2005 11:27:03 -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 ; Fri, 13 May 2005 12:25:16 +0100 Received: from news01.csr.com ([10.103.143.38]) by exchange03.csr.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 13 May 2005 12:28:13 +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 j4DBR0L3014383 for ; Fri, 13 May 2005 12:27:00 +0100 Received: from csr.com (pws@localhost) by news01.csr.com (8.13.1/8.13.1/Submit) with ESMTP id j4DBR0Yt014380 for ; Fri, 13 May 2005 12:27:00 +0100 Message-Id: <200505131127.j4DBR0Yt014380@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: <20050510184600.GA67763@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> Date: Fri, 13 May 2005 12:26:59 +0100 From: Peter Stephenson X-OriginalArrivalTime: 13 May 2005 11:28:13.0916 (UTC) FILETIME=[D9C109C0:01C557AE] 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: > I have an idea, that might not be to difficult to implement, that I > think would solve the problem, unless you know of other problems it > would create. > > If, inside the signal handler, I execute the trap statement on the > same signal, turn off the intrap status because the signal is now > re-trapped. I don't think that's the problem. intrap has a quite limited effect, determining how the shell behaves when already handling signals. The vague suspicion is that the problem is based on whether or not the trap handler is run inside the signal handler, and whether the system resets the signal. It's possible to tweak the queueing code, which would force more traps to be run after the handler exits rather than within it, but I'm really not sure enough about what's going on to suggest anything definite. -- 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. **********************************************************************