Messages in this thread | | | Subject | Re: thread group comments | From | Ulrich Drepper <> | Date | 01 Sep 2000 18:33:42 -0700 |
| |
"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/
| |