[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170220170303.GR1520@brightrain.aerifal.cx>
Date: Mon, 20 Feb 2017 12:03:03 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: No definition of PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP
in musl
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
