lkml.org 
[lkml]   [1998]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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

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