Re: PATCH: Re: Allowing traps

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxxxxx