Re: thread group comments

From: Alon Ziv (alonz@zapper.com)
Date: Sun Sep 03 2000 - 06:19:26 EST


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

Alon Ziv <mailto:alonz@zapper.com>
System Architect (Client Team)
Zapper Technologies Inc. <http://www.zapper.com/>
Tel +972-3-6949226
 





-
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