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: OndÅej BÃlka <neleai at seznam dot cz>
- To: Petr Salinger <Petr dot Salinger at seznam dot cz>
- Cc: roland at hack dot frob dot com, libc-alpha at sourceware dot org
- Date: Mon, 12 May 2014 20:41:05 +0200
- Subject: Re: [PATCH roland/getpid] Simplify getpid handling of the race case.
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LNX dot 2 dot 00 dot 1405100836320 dot 1190 at contest dot felk dot cvut dot cz>
On Sat, May 10, 2014 at 09:01:46AM +0200, Petr Salinger wrote:
> >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.