Messages in this thread |  | | From | "Albert D. Cahalan" <> | Subject | Re: SCO: "thread creation is about a thousand times faster than on native Linux" | Date | Sat, 26 Aug 2000 12:58:43 -0400 (EDT) |
| |
Mitchell Blank Jr writes: > Albert D. Cahalan wrote:
>> First of all, I'd hate to have the kernel enforce an N+1 or N model. >> The kernel ought to be happy with either model. >> >> The PID appears in many annoying places. > > 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.
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.
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.
(unless of course you ask for that: -T -m m -L)
> Think of it this way - instead of a "thread group id" think of > it as a "thread group leader's pid". Numericaly this is the same, > except that that pid is now special (it shouldn't be used for anything > else) > > Now _everywhere_ the kernel currently uses current->pid, make it use this. > This includes getpid, getppid, sysv ipc, af_unix cred, etc, etc. For > non-MT apps that don't use CLONE_PID there is still no change in > behavior. For pthreads programs using this it will look as if all the > threads have the same pid, just like those other os'es. > > 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.
(don't be adding anything _really_ gross to work around this)
>> Every use of PID must be examined to determine if it should keep >> using Linux task IDs or if it should use the new POSIX PIDs. >> Sometimes, as with kill(), we need both options. > > 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. - 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/
|  |