Re: A signal fairy tale

[Dan Kegel]

Christopher Smith wrote:
> 
> At 07:49 PM 6/27/2001 -0700, Daniel R. Kegel wrote:
> >Balbir Singh <[e-mail]> wrote:
> > >sigopen() should be selective about the signals it allows
> > >as argument. Try and make sigopen() thread specific, so that if one
> > >thread does a sigopen(), it does not imply it will do all the signal
> > >handling for all the threads.
> >
> >IMHO sigopen()/read() should behave just like sigwait() with respect
> >to threads.  That means that in Posix, it would not be thread specific,
> >but in Linux, it would be thread specific, because that's how signals
> >and threads work there at the moment.
> 
> Actually, I believe with IBM's new Posix threads implementation, Linux
> finally does signal delivery "the right way". In general, I think it'd be
> nice if this API *always* sucked up signals from all threads. This makes
> sense particularly since the FD is accessible by all threads.

Although I'm looking forward to the day when Linux threading
(perhaps thanks to IBM's enhancements to Gnu Pth) becomes Posix compliant,
for now we need to consider both Posix threads and LinuxThreads.  
I think the proper behavior for sigopen() under the two threading systems would be:

Posix threads: sigopen() would capture signals delivered to the process,
as well as signals delivered by pthread_kill() to the thread that called sigopen().

Current LinuxThreads: sigopen() would only capture signals delivered 
to the thread that called sigopen().

- Dan