lkml.org 
[lkml]   [1999]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: kernel thread support - LWP's
In <19990716170350.A1288@rajpur.iagora.es> Roger Espel Llima (espel@iagora.com) wrote:
>> There is an internal thread used by libpthread. It's called the "manager".
>> It gets created the first time you call pthread_create. It sits blocked
>> in select() on a pipe.
>>
>> Assuming the manager is already active, pthread_create writes a message down
>> that pipe saying "please create another thread". The manager wakes up and
>> creates a new child, which involves a pile of work both before and after the
>> call. In the end it kicks the original thread back awake with a signal.

> [ ... ]

>> 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.

This is just wrong. Adding necessary things in kernel will be MUCH better.
And if API and implementation will be sane enough I'm pretty sure Linus
will not object. Of course someone with enough respect must step up and
develop both parts: kernel changes and LinuxThreads changes...

> 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.

In fact I'm seen patch half-year ago here to support HANDREDS OF THOUSANDS
processes in Linux (on IA32). The only remaining problem is that pid_t is
not big enough ! So clone() based threads are just fine IMHO.




-
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/

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