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".
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.
So beyond adding the new "thread_master_pid" to task_struct, we need
to add:
* Some way to invoke the signal-forwarder kernel thread. In my last
message I suggested doing this with a syscall, but it could even be
done as a device driver if you _really_ wanted. A syscall seems to be
the most consistent with normal practice (as per nfssvc)
* We probably want some way for threads to get their real pid
(sys_getrealpid) so that people wanting to do neat tricks can.
> 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)
The more I think about it, the more it seems that just mandating N+1
is the clean solution.
> Oh, what if the task master is dead?
Under my proposal - not a problem. The kernel only exits the
kernel struct when all the slave threads exit.
-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/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:17 EST