I thought of that. It would definitely simplify the guts, but I have this
nasty suspicion it would break too many things. For example, imagine that
your program is a daemon which has recorded its pid somewhere so it can be
sent SIGHUP when it needs to reread its config files. It did that before
calling pthread_create. The signal will get sent to the manager, not the
thread that's actually listening.
(Of course, the manager could reflect the signal to a "real" thread. That
_could_ get you closer to POSIX thread semantics. It'd double signal
latency and serialize, but correctness is more important than speed...)
>> This sounds reasonable. CLONE_WAIT ? Shouldn't be that hard to implement.
>>
>
>This will probably solve this part of the problem beautifully.
>
>I remember someone (David Wragg <dpw@doc.ic.ac.uk>) once mentioned another
>new flag idea: a CLONE_SIBLING flag, which will mean that if the new
>thread does a clone() the new thread will get the same ppid of the parent.
>This (together with the redefinition of the manager thread, above) will
>mean that all of the threads report directly to the manager, and any
>thread may create another thread _without_ communicating to the manager
>(it just creates a new sibling).
I like it.
>Ehh... What about just doing something similar to the daemon start-up
>code--- a la if (clone(...)) exit(0); ?? (Of course, while taking care to
>cheat well enough that the thread won't notice it's actually a new kernel
>task...)
Would work for initially detached threads (with more overhead), but you can
detach a thread at any point after its creation.
It occurs to me that the library has to do cleanup when a thread exits. It
could be done by the exiting thread _if_ we are prepared to live with the
cleanup not happening when a thread gets kill -9.
zw
p.s. Someone is theoretically rewriting libpthread. It doesn't look likely
to get done anytime soon though.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/