This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH roland/getpid] Simplify getpid handling of the race case.
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Petr Salinger <Petr dot Salinger at seznam dot cz>
- Cc: libc-alpha at sourceware dot org
- Date: Tue, 13 May 2014 11:39:08 -0700 (PDT)
- 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>
> 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