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.