Linus Torvalds wrote:
> >Yes, but:
> > * If we're going to give POSIX threads the illusion of a shared PID then
[...]
> Ahh. But this is exactly where I think your analogy is broken.
>
> You need the illusion of a shared pid for _threads_. But we've already
> agreed that a thread that does an execve() breaks apart from the other
> threads, if for no other reason than the fact that it obviously doesn't
> share the same VM. So we have a phase transition..
Yes, it's not the end of the world it's just something to think about.
If you're giving a "pthread process" the illusion of a single PID and
then that whole "pthread process" disappears when execve happens
then it seems logical that it would keep the pid it had. Otherwise
we might have some user-visable issues... imagine if the pthreader
had written a .pid file in order to allow some future process to
signal it, and then it execve'd a new program to do the real work.
Suddenly the .pid file is pointing at a dead process.
Just to explain where I'm coming from - I'm not trying to claim that
we need to be 100% in the spirit of the 'standard'. In the end it's
not unlikely that some of these corner cases will be missed in the
name of simplicity/efficiency. The discussion is that I'm trying to
advance is "assuming that we DID want to do the 100% complete
implementation, what would it have to look like?" That way we can
get a better idea of where the compromises need to be made.
> More importantly, once you approach the problem from the clone/rfork
> approach, you understand that threads and processes are really the same
> thing on a fundamental level. So you realize that the notion of a
> "process ID" as separate from a "thread ID" is not a sensible notion. A
> thread is a process is a thread, and it has a well-defined ID. It's not
> "thread or process". It's both.
Yes - I really think that the "single PID trickery" stuff should ONLY
apply to pthreads. Anyone natively using clone should have zero
problems with having each thread have a seperate pid. In fact I
think we provide most everything these people desire already (except
the shared signal-queue stuff which is really different than the pthreads
signals anyway) Applying any of this CLONE_PID mess to anyting
other than pthreads would be a bad idea.
> So we realize that the whole notion of a "shared PID" is a broken
> notion. It's not really a shared pid AT ALL, because obviously the
> different lightweight processes have identities of their own.
Yes, there certainly should NOT be multiple threads with the same
current->pid. However, I think we could replace most kernel uses
of current->pid with current->pthread_master->pid. For non-pthread
users this would be no change (current == current->pthread_master)
The relavent case is a pthread arranging for someone else to signal
"itself". Now in the pthread model, as you point out, the thread
is really just a bastard stepson of the process - it's expecting
the benevolant master thread to pass the signal to the "proper"
thread. So when communicating outside the "process" the "thread"
needs to think it's PID is that of the master thread. This is
true if it's writing the result of getpid() to a .pid file, ditto
if it's signalling an external process and counting on siginfo.pid
to have the right number, ditto if the external process is picking
up the pid from a SYSVIPC credential, etc.
So really current->pid should be used mostly for the benefit of
the kernel and /proc. Most everywhere else would use PTHREAD_PID(current)
where:
#ifdef CONFIG_PTHREADS
#define PTHREAD_PID(task) (task->pthread_master->pid)
#define IS_PTHREAD_MASTER(task) (task == task->pthread_master)
#else
#define PTHREAD_PID(task) (task->pid)
#define IS_PTHREAD_MASTER(task) (1)
#endif
> Final piece of the puzzle: we use the (n+1) native threads approach to
> do the n pthreads thing, so that none of the threads that a threaded
> pthreads program will see is actually the process group leader (that
> single thread is the hidden administrator - the puppet master - created
> at the first thread creation).
Yep, that's pretty much it. Force the master thread to do the execve.
In fact, we couldn't probably just make execve fail for any thread that
ISN'T the master pthread (note I said pthread, not clone-thread :-)
and have the pthread library sort this out. That way the pid is
going to be preserved.
> [ Alternative details: regular UNIX process group leadership also
> implies the notion of "orphaned" processes without a group leader.
In the N+1 model I've been advocating the death of the master thread
would imply the death of all its children. Note that this quite
cleanly wraps up the atomic-execve issue - the kernel would just
automatically terminate all the other threads after the pthread
master had execve'ed away on behalf of one of its slaves.
> > * What happens if the execve fails? I suspect POSIX would want us to
[...]
> Actually, I'd personally just prefer trying to find a loophole in POSIX.
Who says that there isn't a role for lawyers in open source development :-)
> Or do it in the loader process, so that the newly executed process
> automatically kills any remnant threads before doing anything else.
Yeah, but you still have to serialize it, at least in userland, or
there's a race where you could end up with two processes execve'd
off the same "pthread process", which is definatly an odd thing to
happen in the pthreads universe (I don't argue that it makes perfect
sense in the clone-universe). But as I detailed above, if you fix
this problem in an N+1 model you automatically fix the pid-change
problem for free.
> in a truly threaded environment. pthreads does tend to assume a fairly
> strictly ordered life (which is natural considering the origins of it,
> but it makes it painful when you have truly independent threads that
> aren't all that strongly synchronized).
Yes, that is why the N+1 implementation is superior, since you can
make the dedicated-master thread do all the things that need strict
serialization. Any pure 'N thread' pthread-on-clone implementation
is going to keep running into these little issues face first, IMO.
-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:20 EST