[lkml]   [2000]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: thread group comments
"Andi Kleen" <> writes:

> But I guess you don't want the context switch to a thread manager just to
> generate a thread ? (and which is one of the main causes of the bad thread
> creation latency in Linux currently)

The thread manager, is I see it in the moment, will consist more or
less of this:

extern volatile int nthreads;
waitpid (0, &res, __WCLONE)
while (nthreads > 0);
exit (WEXITSTATUS (res));

No signal handler, since it cannot receive signals. Everything else
the threads will do themselves.

There is a problem though: the code we currently use for something
like restarting depends on the manager doing this. This can be
implemented in two ways:

- send the manager a signal; this would require the threadkill() syscall
already mentioned. Note that we can assume RT signals and therefore
can transport data. But we get into problems if too many RT signals
are queued.

- extend the loop above to something similar to what we have today:

n = poll (..,..,.., timeout);
check_for_dead_threads(); // use WNOHANG
if (n > 0)
read request and process it
while (nthreads > 0)

I really would like to avoid this. It has the problems we are
seeing today:

* high latency of these requests
* must adjust the priority of the manager (this now gets complicated
since it's not the manager which start the threads)
* problems with changing UID/GID

It will require some investigation to see whether we can implement the
restart semantics correctly without a manager thread. If yes, we
should be able to live with the simple loop.

---------------. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at `------------------------
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.063 / U:0.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site