This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: linuxthreads and signals


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]