Re: changes in pthread signal handling to achieve posix compliance?

[Mark Kettenis <kettenis at wins dot uva dot nl>]

   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