Messages in this thread | | | Date | Sat, 17 Jul 1999 22:48:41 +0300 (IDT) | From | Alon Ziv <> | Subject | Re: kernel thread support - LWP's |
| |
On 16 Jul 1999, Andi Kleen wrote:
> zack@rabi.columbia.edu (Zack Weinberg) writes: > > > > There's another lovely detail: The "initial thread" (the one that was > > executing before the first call to pthread_create) isn't a child of the > > manager; it's the parent of. Per POSIX, the manager has to notice when the > > initial thread goes away and kill all the others. That's why there is a > > getppid in the above. The select times out every two seconds just so it can > > check. > 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?
> Does it require that for kill -9 too?
Hmm... Not a nice problem...
> > 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).
> > > > It would also be handy to have a "disown" call which had the effect of > > immediately reparenting the target process to init. Currently "detached > > threads" have to be waited for too. > > This already exists. Do prctl(PR_SET_DEATHSIG, SOME_NEW_SIGNAL) in the child > and ignore that signal in the parent (at least it should work in theory, > I haven't tested 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...)
> Other things I would like to add to the kernel for better linuxthreads: > > - cmpxchg kernel emulation for 386. > - a vm id for ps support:
Great ideas!
> - support to write register sets for all threads that use the vm into the core > dump.
This is a bit of a problem: currently core dumps are for tasks, not `processes' (which are actually a userspace abstraction, which in the LinuxThreads case is implemented as multiple tasks). We first need some way of telling the kernel that a complete set of tasks is to be terminated now, and all need to dump core to just one coredump file... :-*
(It's probably also related to solving the problem of `how to make a debugger attach to a running multithreaded program...)
-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/
| |