From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10195 invoked from network); 23 Nov 2000 08:11:26 -0000 Received: from sunsite.dk (HELO sunsite.auc.dk) (130.225.51.30) by ns1.primenet.com.au with SMTP; 23 Nov 2000 08:11:26 -0000 Received: (qmail 6167 invoked by alias); 23 Nov 2000 08:11:17 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13184 Received: (qmail 6160 invoked from network); 23 Nov 2000 08:11:16 -0000 Date: Thu, 23 Nov 2000 09:11:13 +0100 (MET) Message-Id: <200011230811.JAA16061@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Wed, 22 Nov 2000 17:33:45 +0000 Subject: Re: PATCH: Re: Allowing traps Bart Schaefer wrote: > ... > > } 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. Of course I have no objections to use a cleaner solution, but will the signal-blocking really allow us to execute more trap handlers immediately? Considering the many places where concurrent execution is unsafe... And who is going to find all the places where we have to block/unblock signals? (To keep the sections with signals blocked short.) Somehow I envision many extra system calls, but I really haven't tried to make a list where we need to keep trap handlers from running, so I may be wrong... Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de