lkml.org 
[lkml]   [2000]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: SCO: "thread creation is about a thousand times faster than on native Linux"
Albert D. Cahalan wrote:
> > That's why I'm thinking more and more that we should just say
> > "if you want POSIX signal semantics, use an N+1 model".
>
> I hate this.
>
> First of all, I dare not code it. Linus seems to want Linux not
> strongly tied to the POSIX thread model. We have non-POSIX thread
> libraries, sorry if you don't like it.

Uh, I don't know where you got that idea... I'd be happy if all we
had was non-POSIX thread libraries. But POSIX is there and there are
good reasons to support it corectly.

The point is that the non-POSIX people seem pretty happy with how
it works now (with every thread with its own PID and own signalling,
etc). This psuedo-single-pid crock is only (as far as I can see)
useful for POSIX.

> Even with POSIX threads, I think we should leave implementation
> choices like "N+1 or N or N:M or N:many" to the library author.

You're confusing two completely seperate issues here:
* N vs N+1 - whether the thread group is symetric (N+1, i.e. slave
threads with one dedicated master thread) or assymetric (N threads
with a random one also acting as the master) This is of no real
concern to the programmer, so we should choose whatever is the
clean implementation.

* N:N, N:M, N:1, etc - this is the ratio of userland threads to kernelland
threads. This has important performance ramifications, and the ideal
solution is the topic of much debate.

Again, these are 100% seperate issues. Just because my proposal forces
a N+1 model doesn't mean that the library can't be N:M or anything else.

> Second of all, as the author of the new "ps", I really want
> non-POSIX thread systems to display as processes. It is not OK
> to have, say, Java processes show up as a hundred distinct tasks.

So you're saying that all non-POSIX threads will be forced to use CLONE_PID
and play these signalling games even if that's not what they want, just
for the benefit of ps? That's silly. CLONE_PID should be the realm of
pthreads, other threading models already get what they want.

I think we just need to realize that "group of threads for pthread-esque
signal handling" and "group of threads for procps pretty printing" need
to be seperate things. For the latter we should just use the simple
mm-id solution.

> > Now when a program starts using pthreads, the initial pid will become
> > the thread-group-leader-pid. This pid just goes into a kernel thread
> > which forwards the singnals. I really think that having this as a
> > seperate kernel thread is the cleanest method since it means no
> > changes to the non-MT case. No peformance hit. No bugs.
>
> This isn't really going to work. You can't just distribute the
> signals as they come in. Sometimes you must keep signals in a
> common pool, then deliver to the first thread that unblocks.

That logic has to go somewhere, no matter what model you use. In my
model you can just keep the pointers to the signal queue on the kernel
stack of the master thread. Shouldn't be too gross.

> > Which is why it's preferable to have a seperate pid acting soley as
> > the "thread master". That way you can refer to eiher with the same
> > API instead of needing a seperate interface each time you want to
> > be able to choose (i.e. kill vs tgkill)
>
> No, kill() must return ESRCH when sent to a task that is not the
> thread group leader.

Is this some POSIX requirement?

In some other email you alluded that this a security measure for
"setuid MT apps". Well, if it's setuid then the user won't be able
to signal it anyway. Or are you thinking of apps that have different
per-thread credentials (so maybe the user could signal the child
threads but not the master)? Well in that case I don't think POSIX
gives you any garauntees and it's not clear what the correct response
is anyway. We certainly don't provide any special protection now.

-Mitch
-
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/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.294 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site