> On Sat, 17 Jul 1999 22:48:41 +0300 (IDT), Alon Ziv wrote:
[...]
> >Wouldn't it be better if the initial thread _became_ the manager thread,
> >and a new thread was implicitly created as a duplicate of what it was
> >doing?
> >Sure, it would need some fiddling (e.g., the `old' thread, which now
> >becomes the manager, will be the one to get a new stack; the old stack is
> >moved to the `new' initial thread). But it would simplify the rest, no?
>
> 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 should (IMO) be done anyway; the manager is responsible for
implementing POSIX signal semantics (unless someone truly prefers the
kludge of `signal-one process groups'... yuck.) [*]
Anyhow, any thread in the program that calls getpid() should get the
original task's pid--- that's what POSIX says. So, when we use pthreads
compatibility, if I write the result of getpid() somewhere, the task that
gets this signal should know what to do with it. And even gettid()
shouldn't really map to the getpid() syscall; it should access
thread-specific memory. So the thread may be `retasked' (ie moved to a
different kernel task) without its knowledge.
> >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
[...]
>
> I like it.
>
Tim Hockin <thockin@isunix.it.ilstu.edu> is working on it now...
>
> >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.
>
So?
The thread will do the above sequence when it's detached. (Sure, whoever
detaches it will need a way to tell it to go away, but it's doable.
Threads communicate all the time anyway... Just send it an RT signal with
enough data that it knows what to do now.)
> 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.
>
Well, if the thread is detached, I see no reason to keep it in the
manager's list anymore. Or am I wrong?
-az
------------------------+----------------------------------------------------
. __ | Phone: +972 3 5340753 (home), +972 3 9685882 (work)
_| / | email: alonz@usa.net
/ | /_ Alon Ziv | smail: 33 Ha-Rama St., Ganey Tiqwah 55900, Israel
------------------------+----------------------------------------------------
<<<(((this place reserved for that ultra-wise oneliner I haven't found.)))>>>
-
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/