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/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:15 EST