[lkml]   [2001]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: A signal fairy tale
Christopher Smith wrote:
> At 07:49 PM 6/27/2001 -0700, Daniel R. Kegel wrote:
> >Balbir Singh <> 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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:55    [W:0.108 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site