Messages in this thread | | | Date | Wed, 24 Jun 1998 11:42:37 +1000 | From | Richard Gooch <> | Subject | Re: Thread implementations... |
| |
David Wragg writes: > 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().
OK, I see.
> > > 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).
Oops. Sorry, mis-read that.
> 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.
Check the CREDITS file (search for "prctl":-). I didn't bother with adding an entry in the MAINTAINERS file, since it didn't seem like such a big deal. I'm quite happy for prctl(2) to be extended the way you suggest. It's just these sorts of things I had in mind.
Regards,
Richard....
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |