From: Linus Torvalds <torvalds@transmeta.com>
Date: 2000-08-24 16:23:34
On Thu, 24 Aug 2000, Andi Kleen wrote:
> For good behaviour you need a shared sigprocmask(). (I just ran
> into a situation where shared signal blocking would have been
> very useful on Linux). You basically want to protect your data
> structures that could be accessed by signals against signals send
> to any thread, otherwise sigprocmask are pretty useless.
I _really_ really want to avoid this. I think POSIX is vague on the
requirement, and quite frankly, a shared sigprocmask() is a horror. It
really doesn't fit in, at all.
POSIX says that the behaviour of sigprocmask() is unspecified for
multi-threaded processes, so there's nothing wrong with leaving
sigprocmask() as it is.
Basically, we can add thread groups with about 10 lines worth of diffs,
and they will be "obviously correct". That means that if this helps
LinuxThreads, it can happen before 2.4.0-final.
I don't think thread groups alone will help LinuxThreads right now.
Not without the proposed changes to the signal handling.
In contrast, a shared sigprocmask() simply isn't going to happen. That is
a 2.5.x issue, and even in 2.5.x I'd really like to avoid it, because it
would be a design mistake, I suspect.
I think even POSIX recognizes that :-).
> [Earlier there were proposals to add a CLONE_WAITPID for that, but I think
> controlling it via the tid and prctl would be more elegant and flexible]
I'd prefer CLONE_WAITPID, I think.
Is CLONE_WAITPID really necessary if we have CLONE_PARENT available?
Using CLONE_PARENT one can just make the initial thread the parent of
all other threads, and keep the initial thread around even after it
calls pthread_exit(). I don't think that's terribly hard to implement.
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 Aug 31 2000 - 21:00:13 EST