This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: changes in pthread signal handling to achieve posix compliance?
- To: khendricks at ivey dot uwo dot ca
- Subject: Re: changes in pthread signal handling to achieve posix compliance?
- From: Mark Kettenis <kettenis at wins dot uva dot nl>
- Date: Tue, 29 Aug 2000 16:38:26 +0200 (MET DST)
- CC: libc-alpha at sourceware dot cygnus dot com
- References: <v03110703b5d167f74325@[129.100.29.243]>
From: "Hendricks, Kevin" <khendricks@ivey.uwo.ca>
Date: Tue, 29 Aug 2000 09:19:44 -0400
Hi,
Given the recent libc-hacker posting about threads and signal delivery and
this announcement from Linus, Is there a good chance that signal handling
will change in 2.4 kernel for linuxthreads to follow the posix thread
standard (i.e. a signal is sent to a "thread group" and *not* a specific
thread and it is handled by whatever thread in the thread group has that
signal unblocked (randomly)?
Looks like the "signal can be delivered to any thread"-stuff is
actually there. Thought that Linus had declared that a 2.5 issue.
This will probably mean some serious changes to linuxthreads internals and
to the jdk specifically (we make use of the thread specific signals to
implement a thread suspend for garbage collection).
Yes, the LinuxThreads internals are likely to change in a not too
distant future. But probably not because of the signal stuff. There
might even be a complete rewrite. Anyway, depending on the
LinuxThreads internals isn't a particular wise thing to do (but read
on).
This seems like a huge change at the linuxthreads level in the glibc code
since they use the thread specific signal approach to control most if not
all individual thread restarts, etc.
Thread specific signals are still possible. So that part of
LinuxThreads doesn't have to be changed.
Is this going to happen? In time for glibc 2.2 or some later time frame?
Will there still be an option to send a thread specific signal?
Any significant changes to LinuxThreads are definitely post glibc 2.2
stuff.
pthread_kill() will always be there.
How do you recommend that application developers react to this news (if at
all)?
If you use clone(2) directly, you might want to take advantage of the
new stuff.
If you use LinuxThreads, be prepared to deal with the old behaviour
for a little longer. And:
* Try to avoid depending on every thread having a distict process id.
* Be carefull with wait() & friends. They might report only children
started by the current thread, or they might report any children
started by the collection of threads that makes up the POSIX
process.
* Don't use setuid() & friends.
Mark