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]

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


   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

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