Re: [PATCH v3 08/37] nptl: Move pthread_once and __pthread_once into libc

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 17/03/2021 14:43, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>>> nss_ldap would silently link to __pthread_once@@GLIBC_PRIVATE instead
>>> after a rebuild.  That's not a step forward, I think.
>>
>> From nss_ldap from where exactly the __pthread_once will be originated?
>> I would expect that building it against 2.34 headers to reference 
>> pthread_once instead.
> 
> It's related to the in-process nature of nss_ldap (without the d),
> LinuxThreads, and pthread_atfork not available in libc at the time:
> 
>   /*
>    * This bogosity is necessary because Linux uses different
>    * PIDs for different threads (like IRIX, which we don't
>    * support). We can tell whether we are linked against
>    * libpthreads by whether __pthread_once is NULL or
>    * not. If it is NULL, then we're not linked with the
>    * threading library, and we need to compare the current
>    * process ID against the saved one to figure out
>    * whether we've forked. 
>    *
>    * --
>    *  __pthread_once does not imply __pthread_atfork being non-NULL!
>    *  <…@redhat.com>
>    * --
>    * 
>    * Once we know whether we have forked or not, 
>    * courtesy of pthread_atfork() or us checking
>    * ourselves, we can close the socket to the LDAP
>    * server to avoid leaking a socket, and reopen
>    * another connection. Under no circumstances do we
>    * wish to use the same connection, or to send an
>    * unbind PDU over the parents connection, as that
>    * will wreak all sorts of havoc or inefficiencies,
>    * respectively.
>    */
> 
> Of course this is all somewhat questionable, but at least there is one
> historic user of that symbol.

Sigh... ok.

> 
> I think we should turn this into a compat symbol once we do not need the
> internal reference (or call it by a different name instead).

Agreed.

> 
>> Right, does call pthread_once from call_once incur in a linknamespace
>> issue?
> 
> Yes, call_once is ISO C, but pthread_once is not a reserved name in
> ISO C.

Fair enough, the patch looks ok then.