On Sun, 17 Nov 2002, Ulrich Drepper wrote:
> >
> > And the point of this is? The child has to re-initialize it's pthread
> > structures anyway after a fork,
>
> No, that's the whole point. The thread descriptor for the one thread in
> the new process is fine with the one exception: the TID. There is not
> one change to the thread descriptor in the fork code left if this change
> is available.
Oh, I realized that, but I was talking about the _other_ thread
descriptors. The ones that exist in the parent (because the parent
potentially has multiple threads before the fork()), but that will be
invalid in the child.
So when the child eventually creates a new thread, it needs to know to
ignore the other thread slots, even though they _look_ valid. They were
valid in the parent, they aren't valid in the child.
No?
I follow your argument, and I don't dislike it per se. I just think that
you end up having to do other setup for pthreads-after-fork _anyway_, no?
I still want to have those flags make _sense_ rather than just adding a
new flag without reason. For example, I've seen no real reason to
introduce a second pointer - as far as I can tell it makes sense in none
of the cases anybody has ever mentioned so far.
Basically, I don't see the patch and bits making sense. I see it
potentially _working_. But that's a different issue - and "working" to me
is sometimes a much less potent argument than "makes sense".
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Nov 23 2002 - 22:00:20 EST