Yes, I know. And as it happens, a few hours after I sent that message
I started thinking about some other application that needs to use
threads, but in this case the "job launching" scheme I've been using
for my computations will no longer do: I need proper mutexes ->
pthreads. So it started me thinking about how to work around the
existing problem.
> 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.
Hmmmmmm. That might just work. It does have the flavour of a hack,
though. The thoughts I had were to add a new mask/parameter to clone()
such as PSIGNAL, which is a mask which tells the parent which signal
to deliver to the child when the parent dies.
An alternative is a new syscall (prctl() ?) which a child can call to
specify that a particular signal should be delivered to it when its
parent dies.
What do people think of this scheme? IMHO this is a bit cleaner than
swapping stacks.
Linus: would you accept a patch for 2.1.x and 2.0.x?
BTW: I find it a bit of a pain when I create a dozen threads per
application that I get a very long process table: it makes it hard to
see other stuff amongst the threaded processes. Is there any
possibility that in the future Linux will in some way hide these extra
processes? Despite its shortcomings, the Solaris model of hidden LWPs
(yes, I know you can see them if you really want) within a single
processes does have some benefits.
Perhaps another flag to clone() such as CLONE_NO_PROC_ENTRY?
Regards,
Richard....