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

[Petr Salinger]

Hi.

> This is implemented by a few lines of assembly for each
> machine, and nowhere is there a comment that explains the rationale.

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

> The difference is that in the libc version, it checks for ->pid being 
> zero and if it's zero instead sets it to 0x80000000 (i.e. an arbitrary 
> negative number).  The libpthread version doesn't do that, so if it's 
> set to zero then it stays that way.

Not really.

The ->pid (and ->tid) is zero after execve().
With libpthread.so linked in, the __pthread_initialize_minimal runs.
Therefore it is guaranteed that during fork() a vfork() the  ->pid is 
non-zero.

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

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'm not very clear on the utility of ever setting ->pid to a negative
> value.  The fork and vfork code never look at the negated value again, 
> they just save the original value locally and restore it later.

See nptl/sysdeps/unix/sysv/linux/raise.c

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.

Petr

P.S.
Please CC me on reply, I am not subscribed to libc-alpha