This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: linuxthreads and signals
- From: Corey Minyard <minyard at acm dot org>
- To: george anzinger <george at mvista dot com>
- Cc: dank at kegel dot com, "libc-alpha at sources dot redhat dot com"<libc-alpha at sources dot redhat dot com>
- Date: Mon, 29 Jul 2002 15:38:27 -0500
- Subject: Re: linuxthreads and signals
- References: <3D438AA0.9E74A37A@kegel.com> <3D458350.7F1B37E7@mvista.com>
george anzinger wrote:
dank@kegel.com wrote:
Now that the Linux kernel has added the "thread group" feature
in an effort to allow standard Posix thread signal semantics, is
anyone updating Linuxthreads to use it?
The NGPT project is using that feature to good advantage, but
they're also adding user-level threading, so they're not what I'm after.
I'm asking about just plain old Linuxthreads (the one included in glibc)
fixed up to have Posix signal semantics.
Thanks,
Dan
A bit more info. In order to use this, the
CLONE_THREADGROUP flag has to be used. This changes a few
more things....
This is somewhat complicated to implement due to the way the the
CLONE_THREAD flag handles signals. All the signal go to the first
thread in the thread group, but to meet POSIX semantics the signal must
go to a thread that doesn't have the signal blocked. So you basically
have to have one thread that receives all the signals and distributes
them out to the other threads. This means pretty big changes to
linuxthread signal handling and sigaction() and buddies. It's not a
small job.
I know, because I have implemented a threads package that uses
CLONE_THREAD (see http://ssthreads.sourceforge.net). It would have been
nice if the NGPT kernel patch had implemented the POSIX semantics for
signal delivery in the kernel, it would make it a breeze to modify
Linuxthreads to work properly and delivery of siginfo information would
then work properly.
-Corey