This is the mail archive of the
mailing list for the glibc project.
Re: Robust getpid caching via MADV_WIPEONFORK?
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: libc-alpha at sourceware dot org
- Date: Thu, 7 Dec 2017 17:29:58 -0200
- Subject: Re: Robust getpid caching via MADV_WIPEONFORK?
- Authentication-results: sourceware.org; auth=none
- References: <20171122203403.hjamn5pwy6q345tf@localhost> <firstname.lastname@example.org>
On 07/12/2017 05:06, Florian Weimer wrote:
> On 11/22/2017 09:34 PM, Josh Triplett wrote:
>> Given that, I wanted to start a thread about the idea of making
>> getpid() caching, and for that matter other potential uses of
>> pthread_atfork(), robust using MADV_WIPEONFORK when available.
> One major issue with the existing PID cache was the interaction with vfork, for calling abort/assert from the subprocess. MADV_WIPEONFORK mappings are not cleared on vfork, so such a PID cache would still return the wrong value in this context.
There were other issues about synchronization and code complexity among
some functions (fork, raise, getpid) which was assuming relaxed atomic
when updating the pthread_t tid field which was not sure it was totally
correct on architectures different than x86_64.
In any case I think if getpid is indeed a hotspot in some programs
a better alternative would to implement as vDSO symbol and let the
kernel handle the synchronization required when its value should change.
I think trying to accomplish it with current different Linux apis