Messages in this thread |  | | Date | Sun, 27 Aug 2000 05:46:30 -0700 | From | Mitchell Blank Jr <> | Subject | Re: 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/
|  |