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

[Ulrich Drepper <drepper at redhat dot com>]

"Hendricks, Kevin" <khendricks@ivey.uwo.ca> writes:

> More specifically, will you still need/use a manager thread in your
> pthreads implementation?  Right now you also use the manager thread to make
> your sem_post asynch signal safe.  If the goal of these changes is to speed
> up thread creation, what changes will occur and when?

If you looked at Linus' changes you will see that they are not
designed to completely obsolete manager threads.  Some other userlevel
problems also make this impossible.  The new model will be like this:

- the initial process, when pthread_create is called for the first time,
  is first creating a clone which takes over the initial threads context
  (stack, registers).  This is necessary because the initial process ID
  now serves as a thread group ID.  You cannot send a signal to such a
  process anymore, only to the entire group.

  The initial thread then becomes something similar to the manager thread.
  It has to reap children and probably has to do some more bookkeeping
  and restarting tasks.


- there always has to be a thread which eats to termination signals.  If
  every thread would call wait() when it expects to have a finishing
  child (this can happen at thread creation time, for instance) there
  is no guarantee which thread will get the notification.  There is the
  __WNOTHREAD flag but the initial thread in its new role must run wait
  without this flag and tehrefore could receive the termination notification.


- thread creation now can happen in the thread calling pthread_create.   It
  will have a really low overhead.  The only nuisance is that there is still
  no CLONE_SUSPENDED flag which lets the child being started in a suspended
  way.  The problem is worsened since now we have three participating threads
  and the only key the initial thread for reaping children has is the PID
  with which it must be able to locate the thread structure to free it.
  It can be made work but it's ugly.


So, the current kernel changes will effect only really the creation.
Most of the rest will have to be handled similarly to what we do now.


As to the availabily: of course no comment.  But it also does not
matter.  The thread library is in an add-on anyway.  The old add-on
will not be replaced.  There will be a new one which hopefully will be
binary compatible (not bug compatible for people who make assumptions
about the implementation).  I don't like the idea of having the code
shared with the old implementation and I also don't like the idea of
backward compatibility with old kernels.  This will be a 2.4 kernel
only add-on which you cannot use unless you enable
--enable-kernel=2.4.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------