From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17273 invoked from network); 14 May 2005 04:36:04 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 14 May 2005 04:36:04 -0000 Received: (qmail 32114 invoked from network); 14 May 2005 04:35:58 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 14 May 2005 04:35:58 -0000 Received: (qmail 26835 invoked by alias); 14 May 2005 04:35:55 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 21260 Received: (qmail 26826 invoked from network); 14 May 2005 04:35:55 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 14 May 2005 04:35:55 -0000 Received: (qmail 31756 invoked from network); 14 May 2005 04:35:55 -0000 Received: from lakermmtao05.cox.net (68.230.240.34) by a.mx.sunsite.dk with SMTP; 14 May 2005 04:35:49 -0000 Received: from quark.hightek.org ([68.12.75.33]) by lakermmtao05.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050514043548.LZRA13442.lakermmtao05.cox.net@quark.hightek.org> for ; Sat, 14 May 2005 00:35:48 -0400 Received: by quark.hightek.org (Postfix, from userid 501) id 721B245918; Fri, 13 May 2005 23:33:38 -0500 (CDT) Date: Fri, 13 May 2005 23:33:38 -0500 From: Vincent Stemen To: zsh-workers@sunsite.dk Subject: Re: localtraps and signal handling on NetBSD Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505131127.j4DBR0Yt014380@news01.csr.com> User-Agent: Mutt/1.4.1i 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 On Fri, May 13, 2005 at 12:26:59PM +0100, Peter Stephenson wrote: > 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. I am not sure I am following you correctly. If, by handler, you are referring to the shell script function signal handler, I don't think queuing more signals to run after the handler exits will help. The fact that it waits until the handler returns before responding to the next signal is the problem. Or are you referring to a handler in the zsh source? I did some more detailed multi-platform testing, that did not involve Z shell's localtraps, to compare the behavior of different shells on different platforms. In this particular test, I focused on just the handling of the same signal once you are inside a signal handler. I thought I would post the results in the hope that it might help. I used my machines and various machines available through the SourceForge.net compile farm. I got the same behavior on every platform, including Linux. Here is my test script: # --------- ----------- 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 $$ # --------- ----------- Since I got the same result on every platform, we are not dealing with any OS specific issues in this particular case. Here are the shells on various platforms that I tested with that correctly handled the signals and produced the output below. PD KSH v5.2.14 99/07/13.2 on NetBSD 2.0 PD KSH v5.2.14 99/07/13.2 on Linux 2.4.21-27.0.1.ELsmp ksh on SunOS x86-solaris1 5.9 ash on Linux 2.4.21-27.0.1.ELsmp sh on NetBSD 2.0 sh on NetBSD 1.6.1 sh on FreeBSD 4.10-BETA sh on OpenBSD 3.4 sh on SunOS x86-solaris1 5.9 main: sending SIGTERM sigterm1(): sending SIGTERM -- sigterm2 -- main: sending SIGTERM sigterm1(): sending SIGTERM -- sigterm2 -- The summary of the results is that the only two shells that do not handle the signals correctly once in the handler are bash and zsh on all platforms. sh on Solaris and all the BSD's, ksh, and ash (commonly available on Linux systems) behaved properly. 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 I believe we thought that the signals were being handled differently in zsh on Linux than BSD earlier, but in this test that does not appear to be the case. In all cases zsh does not process the next signal until it exits the signal handler, so the trap following the kill command resets the signal before the next signal is processed, causing it to loop endlessly. I also got the same result on the patched version of zsh 4.2.5 that we were testing with earlier. main: sending SIGTERM sigterm1(): sending SIGTERM main: sending SIGTERM sigterm1(): sending SIGTERM The problem with bash is that it disables further signals all together once it is in the signal handler and the trap statement does not re-enable them. Either problem can be a show stopper. -- Vincent Stemen Avoid the VeriSign/Network Solutions domain registration trap! Read how Network Solutions (NSI) was involved in stealing our domain name. http://inetaddresses.net/about_NSI.html