Even better: it's even possible to 'cheat' and make _all_ threads be owned
by the LinuxThreads 'manager' thread (basically, this is done by making the
initial thread into the manager and switching its computation to some other
thread). Which means--- just the one special thread in the whole mishmash.
----- Original Message -----
From: "Mark Kettenis" <kettenis@wins.uva.nl>
To: <torvalds@transmeta.com>
Cc: <linux-kernel@vger.kernel.org>; <ak@suse.de>
Sent: Thursday, August 24, 2000 20:03
Subject: Re: SCO: "thread creation is about a thousand times faster than on
> 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/
>
-
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