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/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:18 EST