lkml.org 
[lkml]   [1999]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: linux-kernel-digest V1 #4149
In <Pine.LNX.3.96.990716090909.1928C-100000@walker1-46.reshall.ou.edu> cd_smith@ou.edu (cd_smith@ou.edu) wrote:
c> On Fri, 16 Jul 1999, Khimenko Victor wrote:
>> They are related, but not "related enough" ! It's exactly why LinuxThreads are
>> so slow :-(( `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.'

c> Somehow I doubt that an extra IPC every time a thread exits is "the
c> reason" that LinuxThreads are slow... Have any data to back that up? It
c> is a kludge, but it doesn't really hurt anything too much.

Now. Not additional IPC :-(( It goes further. How thread creation in
LinuxThreads looks ?

<calling thread>
write
sigsuspend
<switch to manager>
select returns
getppid
read
geteuid
mmap, twice
clone
<switch to child>
getpid
<back in manager>
kill
select
<calling thread is awake again>

MUCH more then simple clone() and setting up child's stack :-(( Why all this
mess ? Just since there are no way for task to wait for another "unrelated"
task (I use term "task" for Linux's process/thread beast: it's not process and
it's not a thread so term task looks more appropriate). So all waiting occurs
in manager task and then manager send apropriate signals to it's childs. The end
result look like global kernel lock :-/ Plus ugly thread creation (see above).
To eliminate this you'll need to have some way for tasks... Talk with
Zack Weinberg <zack@rabi.columbia.edu> if you need more details... What you
really want for LinuxThreads is something like this:

bash (pid X)
\-App (pid Y)

first additional thread created

bash (pid X)
+-App (pid Y1) \ ThreadGroup with pid Y
\-App (pid Y2) /

additional thread created

bash
+-App (pid Y1) \
+-App (pid Y11) | ThreadGroup with pid Y
\-App (pid Y2) /

and so on.

So when thred Y1 will be ended Y11 will NOT be orphane ! And bash can use
pid Y to work with App as whole ! It's just a simple idea and may be there
are some hidden problems but this way it's possible to do POSIX semantic
for threads and also more subtle tricks without deep rework of existing
tools (ThreadGroups will be shown in /proc along with tasks and you'll see
in ps even more processes then now but a) it can be easily fixed and b) it's
mostly cosmetic problem anyway :-)




-
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.113 / U:0.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site