[lkml]   [2000]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: thread group comments
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
- 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
- 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?!?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.143 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site