From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2683 invoked from network); 22 Nov 2000 17:34:17 -0000 Received: from sunsite.dk (HELO sunsite.auc.dk) (130.225.51.30) by ns1.primenet.com.au with SMTP; 22 Nov 2000 17:34:17 -0000 Received: (qmail 14002 invoked by alias); 22 Nov 2000 17:34:00 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13182 Received: (qmail 13993 invoked from network); 22 Nov 2000 17:33:55 -0000 From: "Bart Schaefer" Message-Id: <1001122173345.ZM12195@candle.brasslantern.com> Date: Wed, 22 Nov 2000 17:33:45 +0000 In-Reply-To: <1001120173911.ZM10192@candle.brasslantern.com> Comments: In reply to "Bart Schaefer" "PATCH: Re: Allowing traps" (Nov 20, 5:39pm) References: <0G4C000ND1N3ZY@la-la.cambridgesiliconradio.com> <1001120173911.ZM10192@candle.brasslantern.com> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk (Zsh hackers list) Subject: Re: PATCH: Re: Allowing traps MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Nov 20, 5:39pm, Bart Schaefer wrote: } Subject: PATCH: Re: Allowing traps } } On Nov 20, 4:54pm, Peter Stephenson wrote: } } That doesn't fix the problem that the shell will try and run traps already } } in the queue from within shell code called from the trap handler } } Yes, that is a problem. I was about to commit the patch when I began to get really worried about the whole trap-queuing idea. My biggest concern is that a trap that calls `exit' or `return' will be queued, thereby allowing code that should not have run to execute before the trap queue is processed. (My patch would actually make this more likely, which is what stopped me committing it.) Traps are being queued during most of the time the shell is running, and for builtins they're not processed until after each command finishes executing [unless it does I/O with ztrapread/ztrapwrite]. For signals like SIGINT, that when not trapped set flags which may cause commands to be interrupted early, the behavior may become *very* different if the trap is queued; consider: trap 'trap - 2; kill -2 $$' 2 This is especially worrisome in non-interactive shells, which potentially call ztrapread/ztrapwrite much less often. Consider too the number of places where zsh does I/O with stdio functions, during which traps are now (as of 13108) not executed. } There's still one more problem, which is that it might be possible for a } trap to get queued while it's not ignored, but then become ignored before } the queue runs. } } I'm still a bit concerned that there's going to be a bad interaction between } queued signals and queued traps. This is what it comes down to: The problem only occurs with signals that can arrive asynchronously. We already have the signal queueing code to handle that case; if it needs to be applied more widely, we should do that, but I no longer believe that a blanket trap-handler-queue is a good idea. -- 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