On Thu, 15 Aug 2002, Linus Torvalds wrote:
> > okay. And it also makes sense for a newly forked task to know (and cache)
> > its own PID, without having to call getpid() again.
>
> Well, it won't. The pid write is _after_ we've done the copy_mm(), so
> the child will never see it.
hmm.
> That looks like a potential mistake, though - it causes extra COW-faults
> and it also means that this particular optimization (which I kind of
> like) won't work.
>
> However, if you want to fix it, you'd need to either move the
> clone_thread() earlier, or you'd need to move the CLONE_SETTID logic up
> to the generic layer (that latter path may make more sense, since if
> glibc starts using this interface, you obviously need to do this in all
> architectures anyway)
CLONE_SETTID indeed makes more sense in the do_fork() proper, there's
absolutely nothing x86-ish about it.
Ingo
-
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 : Thu Aug 15 2002 - 22:00:41 EST