From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1956 invoked from network); 20 Nov 2000 16:35:04 -0000 Received: from sunsite.dk (HELO sunsite.auc.dk) (130.225.51.30) by ns1.primenet.com.au with SMTP; 20 Nov 2000 16:35:04 -0000 Received: (qmail 12099 invoked by alias); 20 Nov 2000 16:34:50 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13174 Received: (qmail 12086 invoked from network); 20 Nov 2000 16:34:37 -0000 From: "Bart Schaefer" Message-Id: <1001120163422.ZM10149@candle.brasslantern.com> Date: Mon, 20 Nov 2000 16:34:22 +0000 In-Reply-To: <0G4B000QJZK9C5@la-la.cambridgesiliconradio.com> Comments: In reply to Peter Stephenson "Allowing traps" (Nov 20, 4:09pm) References: <0G4B000QJZK9C5@la-la.cambridgesiliconradio.com> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk (Zsh hackers list) Subject: Re: Allowing traps MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Nov 20, 4:09pm, Peter Stephenson wrote: } } I have some shell code using the new trap behaviour which gets upset } if instances of it are not called sequentially. Should we add an } extra flag to block traps explicitly from running when we are inside } doqueuedtraps()? We don't need a flag ... the behavior should be that for all xxx, SIGxxx is blocked when running the trap for that signal. The OS will enforce that if the trap is run directly from the signal handler, so we should emulate it when running the traps in deferred fashion. This could still cause signals to be received in a different order than they would otherwise have been, which is one reason I would have preferred to have reentrancy or limited critical sections rather than deferrals. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net