On Thu, 21 Nov 2002, Jamie Lokier wrote:
> 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(...)
>
Jamie, we've been there, done that. This is precisely the kind of signal
locking cruft we got rid of in LinuxThreads, and which cruft caused it to
be slow. My goal was and still is to isolate signals from the rest of the
kernel APIs as much as possible, while still keeping the traditional
semantics. Check out an strace of a LinuxThreads linked pthread
application and you'll see signal mask manipulation syscalls all around
the place. Check out an NPTL strace, and see all those straightforward
single-syscall operations.
sure, fork() has some overhead larger than signal manipulation costs, but
this does not make the approach right in any way. If all this userspace
cost can be dealt with by doing some simple things in kernel-space, why
not do it?
Ingo
-
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:35 EST