This is the mail archive of the
libc-alpha@sourceware.org
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> <046d2437-efce-1017-e923-64375806b4d6@redhat.com>
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.
>
> Thanks,
> Florian
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
is troublesome.