[ ... ]
> Why is it doing all this crap? Because of another requirement of the POSIX
> thread spec, which hasn't got any air in the conversation yet: Any thread in
> the process can do the equivalent of waitpid for any other thread in the
> process. Linux doesn't allow that; you can only wait for a task that you
> yourself spawned (unless you are init). The workaround is to make all the
> threads children of the "manager". It waits for them and passes back exit
> statuses to the threads calling pthread_join.
In that case, the LinuxThreads implementation should have an easy way to
turn that crap off, by letting apps specify that they won't attempt to
waitpid() from the wrong thread. This way anyone who wants to can
optimize their threaded apps for Linux and get these extremely fast
thread creation times.
You could either do that with an API call and some state variables (e.g
pthread_setopt(NO_STRICT_POSIX_WAITPID, 1);), or by providing two
versions of libpthread, compiled from the same source with bits
#ifdeffed off.
As for the greater debate, I think the arguments for keeping threads
clone()-based are generally good, except for the fact that lazy people
*will* spawn hundreds (if not thousands) of threads, and then wonder why
it's overflowing the process table. Then again, it might be easier to
make the process table scale dynamically than to build an alternative,
partly user-space based thread library just for them.
-- Roger Espel Llima, espel@iagora.com http://www.eleves.ens.fr:8080/home/espel/index.html- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/