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

[Ondřej Bílka]

On Sat, May 10, 2014 at 09:01:46AM +0200, Petr Salinger wrote:
> 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.
>
Another possibility here is offload this to kernel, it should be easy to
add getpid vdso. That would make libc caching redundant. Same thing could
be done with gettid vdso if we decide to add gettid wrapper.