This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH roland/getpid] Simplify getpid handling of the race case.
- From: Petr Salinger <Petr dot Salinger at seznam dot cz>
- To: roland at hack dot frob dot com, libc-alpha at sourceware dot org
- Date: Sat, 10 May 2014 09:01:46 +0200 (CEST)
- Subject: Re: [PATCH roland/getpid] Simplify getpid handling of the race case.
- Authentication-results: sourceware.org; auth=none
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.
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
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.
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.
Please CC me on reply, I am not subscribed to libc-alpha