Ulrich Drepper wrote:
> > Erm, am I getting confused here? I'm assuming that you can block
> > signals in _only_ the thread that is forking, leaving it unblocked in
> > the others. I'm not very familiar with the current threaded signal
> > model - is the blocked-signal mask shared between all of them?
>
> Each thread has it's own mask but that also means that a signal can be
> blocked by all threads except the one forking.
Thread calls cfork(), which does this in the parent:
sigprocmask(...)
// Very short time during which signals aren't delivered.
clone(...)
// Very short time during which signals aren't delivered.
sigprocmask(...)
and the child does this:
current_thread->tid = *argument_to_cfork
sigprocmask(...)
The only time that a signal can be delayed due to the sigprocmask()
calls, if all the other threads have blocked it, is immediately before
and after the clone() call. I.e. zero instructions worth of time :)
It can also be delayed during the clone() call, but that is _already_
true; adding the sigprocmask() calls doesn't change that.
(Note that the _only_ reason for blocking signals is because of the
possibility of the child receiving SIGINT or something like that, and
wanting its own current_thread->tid value to be valid in the signal
handler.)
Here's an idea
--------------
I appreciate that the above method of implementing cfork() isn't as
fast as it could be. On the other hand, it works with a simpler
clone(), and an idea has just appeared in my head:
The above pattern is simpler if we add _another_ clone flag:
CLONE_BLOCKSIGS, meaning "set the child's signal mask to block all
signals". That removes the sigprocmask() calls from the parent.
That could be quite a useful flag in a number of situations, whenever
a child thread or process would like to do more complicated things
before re-allowing signals, such as a few dup() calls to set up
stdin/stdout, for example. (Setting current_thread->tid is just a
special case of that, which its possible to handle with an extra
argument to clone(). The general case cannot be handled in that way.)
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Nov 23 2002 - 22:00:34 EST