"Andi Kleen" <ak@suse.de> 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;
do
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:
do
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 redhat.com `------------------------ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:12 EST