lkml.org 
[lkml]   [1997]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Killing clones
Date
> Yeah, well since I didn't like the idea of a process waking up
> periodically, I've implemented another scheme. The parent sets up a
> pipe, I close the write end in the threads and do a select(2) for
> input in the threads. When the parent dies, the select will
> return. The child threads can then check if ppid has changed. It just
> means I can no longer clone FDs, but that should not be a problem (I
> don't expect to do I/O in the threads, just computations).

Hum. Well, that works for you, but not for LinuxThreads -- folks
are going to expect to be able to share FDs.

I have another idea, that I'd like to bounce off folks, though:

A new flag, CLONE_SWAP, that reverses the sense of the return value
and reverses who gets the new stack. This would make things so that
the manager thread we were spawning becomes the parent, while the
main thread becomes the child.

This could possibly break things in the main thread if someone was
caching and relying on the thread's pid, but I can't think of what
might want to do that.


r~

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