This is the mail archive of the libc-hacker@sourceware.cygnus.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]

linuxthreads idea



A lot of the hair in linuxthreads is due to the thread manager being a child
of the initial thread.  Why not reverse it?  In the libpthread constructor,
call clone() and have the _parent_ jump onto a new stack.  It becomes the
manager thread.  The child proceeds to call main() as usual.

What does this gain us?  The primary advantage I see is that the manager can
now wait for the initial thread as well as later-created threads.  That
means the manager doesn't have to wake up out of its poll() call every so
often to check whether its parent died (it can catch SIGCHLD instead).  And
that means instead of calling poll() there, it could be something else - for
example, the sigsuspend() inside pthread_cond_wait().  In other words, we
could replace the manager pipe with a queue and a condvar.  That should be
much faster.

One problem I can see is that constructors that run before the libpthread
constructor will get an erroneous view of the world (a different PID, for
example).  We could get around that by a trick similar to the one used to
start profiling before constructors are run.  Also, there might be some
complications with signals.

zw


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