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: kaz at ashi dot footprints dot net
- 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:54:20 +0200 (MET DST)
- CC: khendricks at ivey dot uwo dot ca, libc-alpha at sourceware dot cygnus dot com
- References: <Pine.LNX.4.10.10008290719450.17623-100000@ashi.FootPrints.net>
Date: Tue, 29 Aug 2000 07:31:11 -0700 (PDT)
From: Kaz Kylheku <kaz@ashi.footprints.net>
On Tue, 29 Aug 2000, Hendricks, Kevin wrote:
The manager was introduced because threads needed to hang off a
parent to clone() them and to call waitpid(). It has become useful
for other reasons. For example, the thread manager plays a role in
coordinating process shutdown, and the async-safe sem_post that you
mention.
With Linux 2.4, the manager thread probably won't be necessary anymore
for creating threads.
It's unlikely that the manager thread can be removed, and it
doesn't sound like the signal related work is going to provide any
kernel functionality that could replace the manager. (Also, the GDB
maintainers would probably kill us).
No I won't :-). I'm going to check in some new threads debugging
stuff to GDB in the near future, and it doesn't treat the manager
thread in a special way.
But some sort of "manager thread" will probably still be necessary,
for example for a POSIX-conforming implementation of exec(). This
role will probably have to be played by the "threadgroup leader" though.
> I guess I am asking, is this something I need to worry about for
> glibc 2.2 and kernel 2.4 or would changes like this be restricted
> to some glibc 2.2.X or higher release?
Any experimental work done by kernel 2.4 would have to be carefully
coded around; the library can't assume that it's running on a
patched 2.4 kernel with some neat new signal handling. It would
have to do some run-time detection, similar to what has been done,
for example, to detect whether real time signals are supported or
whether SMP is present.
I really think this is glibc 2.3 stuff. We may even have to bump the
soname for libpthread.so, and support the new libpthread only on Linux
2.4.
Someone has to look at the new signal handling and think about how
to integrate it with minimal impact.
Or else Linux will remove the threadgroup stuff again :-|.
Mark