[PATCH roland/getpid] Simplify getpid handling of the race case.

[Roland McGrath]

> I tried to understand this hackery during porting nptl to kFreeBSD.

Thanks for pitching in with the explanation.

> But without libpthread.so linked in, the ->pid (and ->tid) might be
> zero even during fork() a vfork() calls.

I was starting to suspect this but doubting it could be the intended plan.
Now I see that is really is.  The extra complexity required by this does
not really seem warranted just to avoid one getpid syscall at startup.

> The nptl variant is just optimized with assumption that pid cannot be 
> zero. The 0x80000000 is not arbitrary negative number, but the only
> negative number, that does not have corresponding positive number
> in 32 bits.

I see.  The raise.c code is the only clue to the importance of the exact
value, and it all lacks adequate comments.

Does anybody think that optimizing away these 2-3 instructions warrants the
complexity of having separate libpthread and libc implementations of vfork?
For my immediate work of consolidating NPTL code, I'm inclined to just make
everything use the (slightly longer) libc version of the code.

Cleaning up the whole situation further is more work for later, and is not
on my current priority list.

> The situation when both ->pid and ->tid are zero means,
> that the program is single threaded (w/o libpthread.so linked in), 
> fork/vfork does not run. Therefore it is the right time to store real pid 
> into ->pid for future cached usage. Your change does not do that,
> it is a significant regression.

Agreed.


Thanks,
Roland