No definition of PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP in musl

No definition of PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP in musl

[Raphael Cohn]

[-- Attachment #1: Type: text/plain, Size: 587 bytes --]

Hi,

Whilst trying to compile ReOpenLDAP (https://github.com/ReOpen/ReOpenLDAP),
a fork of OpenLDAP, I'm running into a wall. Some of the code wants a
definition of PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP. musl doesn't define
this; I suspect this is a non-portable glibc extension in pthread.h. Does
any one have any ideas how I might workaround this? Is there an alternative
construction that the code could use?

Any help gladly appreciated.

Raph

PS I'm trying to build the fork, as I'm led to believe it supports
LibreSSL. Patches to support LibreSSL are not in mainline OpenLDAP...

[-- Attachment #2: Type: text/html, Size: 752 bytes --]

Re: No definition of PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP in musl

[Markus Wichmann]

On Mon, Feb 20, 2017 at 03:22:41PM +0000, Raphael Cohn wrote:
> Hi,
> 
> Whilst trying to compile ReOpenLDAP (https://github.com/ReOpen/ReOpenLDAP),
> a fork of OpenLDAP, I'm running into a wall. Some of the code wants a
> definition of PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP. musl doesn't define
> this; I suspect this is a non-portable glibc extension in pthread.h. Does
> any one have any ideas how I might workaround this? Is there an alternative
> construction that the code could use?
> 

Well, not directly.

PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP is an initializer that makes a
mutex recursive. What you could do is look for a single use
initialization function. Then you could replace

static pthread_mutex_t mut = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;

with

static pthread_mutex_t mut;

...
    pthread_mutexattr_t mutattr = {0};
    pthread_mutexattr_init(&mutattr);
    pthread_mutexattr_settype(&mutattr, PTHREAD_MUTEX_RECURSIVE);
    pthread_mutex_init(&mut, &mutattr);
    pthread_mutexattr_destroy(&mutattr);
...

That's the portable way to do it. However, the nonportable solution is
generally used to avoid the one-time initialization otherwise necessary.
As such, there may not be a place for you to put the above snippet. In
that case you may have to introduce such a function.

Alternatively, you could look up the effects the above snippet has on
the mutex under musl, at least at the moment, and declare the
nonportable initializer yourself. At the moment, I think it would be

#define PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP {{PTHREAD_MUTEX_RECURSIVE}}

> Any help gladly appreciated.
> 

Hope it helps.

> Raph
> 

Ciao,
Markus

Re: No definition of PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP in musl

[Rich Felker]

On Mon, Feb 20, 2017 at 03:22:41PM +0000, Raphael Cohn wrote:
> Hi,
> 
> Whilst trying to compile ReOpenLDAP (https://github.com/ReOpen/ReOpenLDAP),
> a fork of OpenLDAP, I'm running into a wall. Some of the code wants a
> definition of PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP. musl doesn't define
> this; I suspect this is a non-portable glibc extension in pthread.h. Does
> any one have any ideas how I might workaround this? Is there an alternative
> construction that the code could use?
> 
> Any help gladly appreciated.

This omission is intentional; the layout of pthread objects is kept
opaque so that it's free to change and we don't get locked into a
layout that turns out to be bad, like what happened to glibc -- they
ran out of space for doubly-linked-list pointers needed for robust
mutexes, so they use a singly linked list and unlock is O(n) where n
is the number of mutexes locked! This also means we can't duplicate
the glibc layout (because it was bad) so from an interest of partial
ABI compatibility, it's better to just say "these non-portable
extension initializers are not supported and don't work" than to have
our own mismatching definitions for them.

To fix the issue, you need to use pthread_once to initialize the
recursive mutex on first use if it has static storage duration. If
it's allocated or automatic, just initialize it at the time of
creation, before any other threads can be aware of its existence.

Rich

Re: No definition of PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP in musl

[Rich Felker]

On Mon, Feb 20, 2017 at 05:24:19PM +0100, Markus Wichmann wrote:
> On Mon, Feb 20, 2017 at 03:22:41PM +0000, Raphael Cohn wrote:
> > Hi,
> > 
> > Whilst trying to compile ReOpenLDAP (https://github.com/ReOpen/ReOpenLDAP),
> > a fork of OpenLDAP, I'm running into a wall. Some of the code wants a
> > definition of PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP. musl doesn't define
> > this; I suspect this is a non-portable glibc extension in pthread.h. Does
> > any one have any ideas how I might workaround this? Is there an alternative
> > construction that the code could use?
> > 
> 
> Well, not directly.
> 
> [...]
> 
> Alternatively, you could look up the effects the above snippet has on
> the mutex under musl, at least at the moment, and declare the
> nonportable initializer yourself. At the moment, I think it would be
> 
> #define PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP {{PTHREAD_MUTEX_RECURSIVE}}

This is a very bad idea, and _will_ break when (not if, when) we
change the layout. It's made opaque for a good reason.

Rich

Re: No definition of PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP in musl

[Raphael Cohn]

[-- Attachment #1: Type: text/plain, Size: 1925 bytes --]

On 20 February 2017 at 16:24, Markus Wichmann <nullplan@gmx.net> wrote:

> On Mon, Feb 20, 2017 at 03:22:41PM +0000, Raphael Cohn wrote:
> > Hi,
> >
> > Whilst trying to compile ReOpenLDAP (https://github.com/ReOpen/
> ReOpenLDAP),
> > a fork of OpenLDAP, I'm running into a wall. Some of the code wants a
> > definition of PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP. musl doesn't
> define
> > this; I suspect this is a non-portable glibc extension in pthread.h. Does
> > any one have any ideas how I might workaround this? Is there an
> alternative
> > construction that the code could use?
> >
>
> Well, not directly.
>
> PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP is an initializer that makes a
> mutex recursive. What you could do is look for a single use
> initialization function. Then you could replace
>
> static pthread_mutex_t mut = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
>
> with
>
> static pthread_mutex_t mut;
>
> ...
>     pthread_mutexattr_t mutattr = {0};
>     pthread_mutexattr_init(&mutattr);
>     pthread_mutexattr_settype(&mutattr, PTHREAD_MUTEX_RECURSIVE);
>     pthread_mutex_init(&mut, &mutattr);
>     pthread_mutexattr_destroy(&mutattr);
> ...
>
> That's the portable way to do it. However, the nonportable solution is
> generally used to avoid the one-time initialization otherwise necessary.
> As such, there may not be a place for you to put the above snippet. In
> that case you may have to introduce such a function.
>
> Alternatively, you could look up the effects the above snippet has on
> the mutex under musl, at least at the moment, and declare the
> nonportable initializer yourself. At the moment, I think it would be
>
> #define PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP {{PTHREAD_MUTEX_RECURSIVE}}
>
> > Any help gladly appreciated.
> >
>
> Hope it helps.
>
> > Raph
> >
>
> Ciao,
> Markus
>

Thank you Markus and Rich for your help and suggestions. I have a good idea
how to tackle this now.

[-- Attachment #2: Type: text/html, Size: 2638 bytes --]