changes in pthread signal handling to achieve posix compliance?

["Hendricks, Kevin" <khendricks at ivey dot uwo dot ca>]

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)?

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).

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.

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?

How do you recommend that application developers react to this news (if at
all)?

Any info would be greatly appreciated.

Thanks,

Kevin


>From: Linus Torvalds torvalds@transmeta.com
>To: Kernel Mailing List
> Subject: test8-pre1
>
> - talk is cheap. The thread group stuff is there. But it will be removed
> unless somebody actually takes a look at whether it really makes
> pthreads easier and more efficient.
> Most of the thread group code is trivial. The biggest impact was on
> signal.c, and even that wasn't because the new code is hard, it's just
> because I split up the "signal sending function from hell" into many
> smaller functions.

--
Kevin B. Hendricks, Associate Professor of Operations and Information
Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario  N6A-3K7  CANADA
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959