Re: Thread implementations...

[Richard Gooch]

David Wragg writes:
> Richard Gooch <[e-mail]> 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....