From: Linus Torvalds <torvalds@transmeta.com>
Date: 2000-09-01 22:06:52
On 1 Sep 2000, Ulrich Drepper wrote:
> 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.
Looking through the code in test8-pre1, I think there are more
problems with (non-fatal) signals:
* sys_rt_sigqueueinfo() calls kill_proc_info() (to avoid the
"signal-to-pgid" semantics), but I think it should be calling
kill_tg_info().
* SIGCONT isn't handled correctly:
"[W]hen SIGCONT is generated for a process all pending stop signals
for that process shall be discarded."
There is an ambiguity in the language here; should a SIGCONT
generated for a thread-group discard a pending stop signal that was
generated for a specific thread? Probably yes. Similar language is
used for the stop signals (with respect to discarding SIGCONT), and
in that case Linux discards a SIGCONT generated for a specific
thread.
In the current implementation all threads are continued until we
encounter a thread that doesn't have SIGCONT blocked and doesn't
ignore it. This probably means that job-control is broken for
thread groups.
* SIGTSTP, SIGTTIN, SIGTTOU seem to be mishandled too:
"When a signal is delivered to a thread, if the action of that
signal specifies termination, stop, or continue, the entire process
shall be terminated, stopped or continued, respectively."
Uli already addresses his concerns about termination by a fatal
signal, but it looks as if similar problems exist for the signals
that stop the process. The default action for SIGTSTP, SIGTTIN or
SIGTTOU should be to stop all threads in the process.
This also seems to affect SIGCONT, i.e. what should be done for a
SIGCONT sent to a specific thread? The requirement that the entire
process shall be continued seems to imply that it isn't possible to
use SIGCONT to continue a specific thread. In a POSIX world
however, the only way such a signal could be generated by
pthread_kill(). This means that the process wasn't stopped in the
first place.
* The interaction between thread-groups and process-groups seems to be
wrong:
Right now when a signal is sent to a process-group, it will be sent
to all tasks in the process-group. I think however, that the signal
should be "sent" only to thread-group leaders in the process-group
and distributed to the threads according to the rules set by
kill_tg_info().
> 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.
How? By letting the thread-group leader trace its cloned children,
and play tricks with PTRACE_SYSCALL? Or are you going to change
things such that CLONE_PTRACE makes clone() send a SIGSTOP to the
newly created child (similar to a patch I sent you before?).
Doesn't this interfere with debugging?
Mark
-
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:13 EST