lkml.org 
[lkml]   [1998]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Thread implementations...
From
Date
Richard Gooch <Richard.Gooch@atnf.csiro.au> writes:
> David Wragg writes:
> > - The "process exit" message remain, but it is probably possible to
> > use a signal for this.
>
> What's this one?

When a thread calls the C library exit() function, all threads have to
terminate abruptly (using the _exit syscall), except for the exit()
caller. The "process exit" message coordinates this in some way
(you'll have to pour over the LinuxThreads source for details).

Now you mention it, perhaps this can be done very tidily: the exit()
caller thread uses an atexit() handler to kill off all threads except
itself and the manager thread, the manager thread then waits to get
the exit value when the exit() caller terminates, which it then passes
on to _exit().

>
> > 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).
>
> If a thread cleans itself up properly, then it can just call prctl(2)
> again and set the signal to 0 (disabling the signal).

This is the child death signal (received by the manager when a thread
terminates) rather than the parent death signal (recieved by a thread
when the manager terminates).

Is prctl "ours"? Could it be extended to allow a process to change or
disable its child death signal (like clone() does, only later
on). I'd rather not add a new syscall for this.

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