Re: thread group comments

From: Mark Kettenis (
Date: Sat Sep 02 2000 - 06:58:43 EST

   From: Linus Torvalds <>
   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

* 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

  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

  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

> 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?

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

This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:13 EST