Messages in this thread | | | From | "Alon Ziv" <> | Subject | Re: thread group comments | Date | Sun, 3 Sep 2000 13:13:35 +0200 |
| |
I find I have to comment... although I haven't had access to my Linux box for a while (Real Life is taking too much of my time ;-)
I, for one, am _not_ in favor of the tgid approach. I believe it is _far_ too complex a solution. And, yes, I do have a better (IMNSHO) approach. I just didn't get enough time to code it. It feels _really_ rude to counter code with words. Oh well.
What I believe should be done is just a few (simple) extensions to prctl. Specifically, what we need is * prctl(SEND_ME_PARENT_SIGNAL_x, s) --- tells kernel 'if my parent gets signal x, send me signal s' (signals will be queued atomically). This way, a thread can ask the kernel to be killed / stopped together with its parent. * prctl(SIGNAL_ON_PARENT_EXEC, s) --- when parent _successfully_ exec's, send me signal s. And that is _all_. No tgid mess, no specific handling of specific signals in the kernel, no 'all threads are blocking this signal' mess, no nada.
Now, userspace will be a different story. There, we'll need the following: - When process does pthreads_init, it creates a new thread (N+1 model); control returns via the _new_ thread (a la userspace thread-switch), and original thread (which has the original pid) remains as master in a special routine. - Whenever a signal is handled _anywhere_ in the process, the master thread sets a handler for it. It's the master thread's job to distribute signals; also, when signal is blocked, it remains on master's queue. (If CLONE_SIGNAL lets thread do the sigaction setup by itself--- even better, less ITC :-) - New threads are created CLONE_PARENT. They ask to get SIGKILL on parent SIGKILL, SIGSTOP on parent SIGSTOP, possibly also SIGSEGV on parent SIGSEGV (and other 'terminating' signals). They also ask to get SIGKILL on parent exec(). - Userspace exec() is rerouted (in _userspace_) to master thread. If it succeeds, all other threads automagically disappear (they were SIGKILLed by their own request); if it fails, return code gets back to originating thread via same ITC mechanism.
Now, just when do I find the time to get a test8-pre1, rip out the silly tgid stuff, and code my idea?!?
-az
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |