lkml.org 
[lkml]   [1998]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Thread implementations...
From
Date
MOLNAR Ingo <mingo@valerie.inf.elte.hu> writes:
> wondering, just to stay in line with other CLONE_ flags, wether we should
> call this 'CLONE_PPID'. This is just yet another 'splitup' of thread
> properties, and makes it possible to share ppid. It might also make sense
> to really share this info just like say signal structures are shared. It
> adds _some_ overhead to access p->ppid (we'd have to access p->pid->ppid),
> but it's more streamlined with the original clone() concepts. It also
> makes guarantees that whenever the manager thread dies unexpectedly, the
> kernel can link all 'orphans' to the manager thread's parent properly, so
> the pid tree never gets out of sync.

CLONE_PPID does have a nice ring to it.

So far the kernel changes are so small that I'm just going to use this
as a test bed for enhancing LinuxThreads. Later I'll work out how
ambitious to be about extending to support fully POSIX threads.

Unexpected thread manager death is handled nicely by having each
thread call prctl() so that they get SIGKILLed when the manager thread
(their parent) dies.

> > The changes to the kernel are tiny, it fixes one problem nicely, and
> > doesn't seem to create any new ones.
>
> this is really cool. Have you measured the performance of pthread_create()
> before and after this change?

I've hacked support into the kernel, and written a non-LinuxThreads
test program to make sure CLONE_MINOR works properly. Measuring the
performance difference is my aim, but it is still a few days away ;-)

And right now I'm working out exactly how to rebuild
glibc-LinuxThreads on it's own...

> Another thing i noticed in LinuxThreads is
> is the 'manager pipe' communication overhead, is this still is present?
> Not sure how this could be avoided though :(

It might be possible. Of the four messages currently used:

- The "create a thread" message becomes unnecessary.

- The "thread exit" message becomes unnecessary because the manager
receives the child death signal.

- The "main thread exit" is handled because the manager thread _is_
the main thread.

- The "process exit" message remain, but it is probably possible to
use a signal for this.

Having the manager thread receive a child death signal each time a
thread exits is, although necessary in some cases, an unnecessary
overhead in others (since usually a thread will clean up after itself
and then call _exit()). I haven't though of a nice way to avoid this
(yet).

--
Dave Wragg

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

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