mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: No definition of PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP in musl
Date: Mon, 20 Feb 2017 12:03:03 -0500	[thread overview]
Message-ID: <20170220170303.GR1520@brightrain.aerifal.cx> (raw)
In-Reply-To: <CACCP0Gp59ghH1t-=ixSApgjhL6A56WkVu2LXH_K5VUJCF9C2KA@mail.gmail.com>

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


      parent reply	other threads:[~2017-02-20 17:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-20 15:22 Raphael Cohn
2017-02-20 16:24 ` Markus Wichmann
2017-02-20 17:03   ` Rich Felker
2017-02-20 17:21   ` Raphael Cohn
2017-02-20 17:03 ` Rich Felker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170220170303.GR1520@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).