Messages in this thread | | | From | "Khimenko Victor" <> | Date | Fri, 16 Jul 1999 19:15:52 +0400 (MSD) | Subject | Re: 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/
| |