Good that _somebody_ actually looked at the code. I'll make some more
modifications to handle blocked signals correctly (ie handling the case
where the signal is blocked in all threads and then unblocked in one of
them _after_ it was delivered), but I've been disappointed by how much hot
air there's been on the list, and how little comments on how the actual
code works.
Thanks, Uli/.
On 1 Sep 2000, Ulrich Drepper wrote:
>
> 1st Problem: One signal handler process process-wide
>
> What is handled correctly now is sending signals to the group. Also
> that every thread has its mask. But there must be exactly one signal
> handler installed. I.e., a sigaction() call to set a new handler has
> consequences process-wide. Since this muse be atomic I think the
> information should be kept in the thread group leader's data
> structures and the other threads should simply use this information
> all the time. Yeah, I know, one more indirection.
We already do this. This is exactly what CLONE_SIGHAND does.
Having looked at the problem some more, it appears to never really make
sense to have CLONE_THREAD and CLONE_SIGHAND be separate. Basically,
either you share signals or you don't. Pthreads shares them. I'll make it
a single flag, and we'll have CLONE_SIGNAL (same as old CLONE_SIGHAND),
and that will be a "signal group" aka "thread group".
> 2nd Problem: Fatal signal handling
>
> kernel/signal.c contains:
>
> * Send a thread-group-wide signal.
> *
> * Rule: SIGSTOP and SIGKILL get delivered to _everybody_.
>
> That's OK. Except that is a signal whose default action is to
> terminate the process is not caught be the application, this signal is
> also handled process-wide. E.g., if there is no SIGSEGV handler the
> whole process is terminated.
Fair enough.
> 3rd Problem: one uid/gid process-wide
>
> All the ID (uid/guid/euid/egid/...) must be process wide. The problem
> is similar to the signal handler. I think one should again keep the
> information exclusively in the master thread and have all others refer
> to this information.
No, it would be another "clone" option.
But I don't think this is performance-critical, and I don't think it is
something people really care about. So I'd be unlikely to handle this for
2.4.x.
> 4th Problem: thread termination
>
> In general, thread termination is not of much interest for the rest of
> the system. It is in the moment but if the fatal signal handling is
> done this will change.
>
> If a thread gets a fatal signal, the whole process is killed. No
> cleanup necessary. Signal handlers can be installed if necessary.
>
> If a thread terminates naturally and can perform the cleanup itself.
>
> In any case, the death signal should be ignored. Except for the last
> thread, of course, which has to notify the process starting the MT
> application.
This is why you should have the "n+1" approach. The "+1" thing is the one
that sees the "n" threads die. The parent of the threaded process is the
one that sees the "+1" die.
> I can see two possible solutions, neither of which I've tried:
>
> - the termination signal given to clone calls is 0 (zero). So no
> notification is sent out. Question is: does the kernel allow this?
Yes, as far as I can tell. I still don't think you should do it directly
like this.
> 5th Problem: suspended starting
>
> Related to the last problem a good old friend pops up. Depending on
> the solution of the last problem it might be necessary to add
> suspended starting of threads. The problem is that sometimes the
> starter has to modify parameters (e.g., scheduler) of the newly
> started thread before it can actually start working. If this fails,
> the new thread must be terminated immediately. But who will get the
> termination signal? The data structures for the new thread must be
> removed as well and this after the new thread is guaranteed to be
> vanished.
You can actually do this with CLONE_PTRACE right now.
Linus
-
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:12 EST