Robust shared mutexes?

Robust shared mutexes?

[Sebastian Kemper]

Hello all,

I'm cross-compiling for OpenWRT/LEDE and have this variable
apr_cv_mutex_robust_shared. Should I set it to yes or no with musl? I've
searched around but found conflicting infos. One post said there's no
shared mutex support in musl and the other said there is. And if there
is support for it then I'm not sure how robust it is :D

Other variables that I think are set correctly but if you disagreed I'd
be happy to hear about:

ac_cv_va_copy=yes
ac_cv_func_realloc_0_nonnull=yes
ac_cv_func_malloc_0_nonnull=yes
ac_cv_func_setpgrp_void=yes
ac_cv_func_pthread_rwlock_init=yes

Please keep me on CC if you reply as I'm not subscribed to this list.

Kind regards,
Sebastian

Re: Robust shared mutexes?

[Rich Felker]

On Sat, Nov 26, 2016 at 10:49:44PM +0100, Sebastian Kemper wrote:
> Hello all,
> 
> I'm cross-compiling for OpenWRT/LEDE and have this variable
> apr_cv_mutex_robust_shared. Should I set it to yes or no with musl? I've
> searched around but found conflicting infos. One post said there's no
> shared mutex support in musl

Do you have a link for that? If there's incorrect information I'd like
to reply and see if it can be corrected.

> and the other said there is. And if there
> is support for it then I'm not sure how robust it is :D

musl fully supports robust mutexes, process-shared or not. They are a
requirement for current POSIX.

> Other variables that I think are set correctly but if you disagreed I'd
> be happy to hear about:
> 
> ac_cv_va_copy=yes

Yes. This is true for any conforming C implementation.

> ac_cv_func_realloc_0_nonnull=yes
> ac_cv_func_malloc_0_nonnull=yes

Yes. These are not strict requirements, but if malloc(0) returns a
null pointer, behavior of realloc becomes a huge mess. All reasonable
implementations should return a unique pointer for each malloc(0)
call.

> ac_cv_func_setpgrp_void=yes

Yes, this is a POSIX requirement.

> ac_cv_func_pthread_rwlock_init=yes

Yes. So is this.

> Please keep me on CC if you reply as I'm not subscribed to this list.

OK.

Rich

Re: Robust shared mutexes?

[Sebastian Kemper]

On Sat, Nov 26, 2016 at 05:24:43PM -0500, Rich Felker wrote:
> On Sat, Nov 26, 2016 at 10:49:44PM +0100, Sebastian Kemper wrote:
> > Hello all,
> > 
> > I'm cross-compiling for OpenWRT/LEDE and have this variable
> > apr_cv_mutex_robust_shared. Should I set it to yes or no with musl? I've
> > searched around but found conflicting infos. One post said there's no
> > shared mutex support in musl
> 
> Do you have a link for that? If there's incorrect information I'd like
> to reply and see if it can be corrected.

Hello Rich,

Thank you very much for the reply!

I looked for the link and it turns out it was an error on my part. The
post wasn't referring to robust shared mutexes. It was regarding process
shared mutexes

http://lists.openembedded.org/pipermail/openembedded-core/2016-March/119214.html

It says musl doesn't have process shared mutexes so one should set
apr_cv_process_shared_works=no. I take it that is correct?

Again, thank you for taking the time!

Kind regards,
Sebastian

Re: Robust shared mutexes?

[Rich Felker]

On Sat, Nov 26, 2016 at 11:51:05PM +0100, Sebastian Kemper wrote:
> On Sat, Nov 26, 2016 at 05:24:43PM -0500, Rich Felker wrote:
> > On Sat, Nov 26, 2016 at 10:49:44PM +0100, Sebastian Kemper wrote:
> > > Hello all,
> > > 
> > > I'm cross-compiling for OpenWRT/LEDE and have this variable
> > > apr_cv_mutex_robust_shared. Should I set it to yes or no with musl? I've
> > > searched around but found conflicting infos. One post said there's no
> > > shared mutex support in musl
> > 
> > Do you have a link for that? If there's incorrect information I'd like
> > to reply and see if it can be corrected.
> 
> Hello Rich,
> 
> Thank you very much for the reply!
> 
> I looked for the link and it turns out it was an error on my part. The
> post wasn't referring to robust shared mutexes. It was regarding process
> shared mutexes
> 
> http://lists.openembedded.org/pipermail/openembedded-core/2016-March/119214.html
> 
> It says musl doesn't have process shared mutexes so one should set
> apr_cv_process_shared_works=no. I take it that is correct?

No, it's incorrect and I have no idea where that idea came from. I'll
ask Khem.

Rich

Re: Robust shared mutexes?

[Szabolcs Nagy]

* Rich Felker <dalias@libc.org> [2016-11-26 17:56:18 -0500]:
> On Sat, Nov 26, 2016 at 11:51:05PM +0100, Sebastian Kemper wrote:
> > 
> > http://lists.openembedded.org/pipermail/openembedded-core/2016-March/119214.html
> > 
> > It says musl doesn't have process shared mutexes so one should set
> > apr_cv_process_shared_works=no. I take it that is correct?
> 
> No, it's incorrect and I have no idea where that idea came from. I'll
> ask Khem.
> 

apr might care about sharing mutexes across i386 vs x86_64 ?

that does not work (glibc ditto)

Re: Robust shared mutexes?

[Sebastian Kemper]

On Sat, Nov 26, 2016 at 05:56:18PM -0500, Rich Felker wrote:
> On Sat, Nov 26, 2016 at 11:51:05PM +0100, Sebastian Kemper wrote:
> > 
> > http://lists.openembedded.org/pipermail/openembedded-core/2016-March/119214.html
> > 
> > It says musl doesn't have process shared mutexes so one should set
> > apr_cv_process_shared_works=no. I take it that is correct?
> 
> No, it's incorrect and I have no idea where that idea came from. I'll
> ask Khem.
> 
> Rich

Hello Rich,

Super, my problem is solved, then :-) Thanks for clearing that up!

Kind regards,
Sebastian

Re: Robust shared mutexes?

[Sebastian Kemper]

On Sun, Nov 27, 2016 at 12:01:10AM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.org> [2016-11-26 17:56:18 -0500]:
> > On Sat, Nov 26, 2016 at 11:51:05PM +0100, Sebastian Kemper wrote:
> > > 
> > > http://lists.openembedded.org/pipermail/openembedded-core/2016-March/119214.html
> > > 
> > > It says musl doesn't have process shared mutexes so one should set
> > > apr_cv_process_shared_works=no. I take it that is correct?
> > 
> > No, it's incorrect and I have no idea where that idea came from. I'll
> > ask Khem.
> > 
> 
> apr might care about sharing mutexes across i386 vs x86_64 ?
> 
> that does not work (glibc ditto)

Hello Szabolcs, list,

I installed a Gentoo musl-1.1.15 x86_64 chroot on my computer. Then I
ran ./configure in apr-1.5.2 in the musl chroot and also outside the
chroot in a glibc-2.22 environment.

The outcome was the same except for apr_cv_mutex_robust_shared:

ac_cv_func_setpgrp_void         musl yes glibc yes
ac_cv_file__dev_zero            musl yes glibc yes
apr_cv_tcp_nodelay_with_cork    musl yes glibc yes
apr_cv_mutex_recursive          musl yes glibc yes
ac_cv_func_pthread_rwlock_init  musl yes glibc yes
apr_cv_type_rwlock_t=yes        musl yes glibc yes
apr_cv_process_shared_works     musl yes glibc yes
apr_cv_mutex_robust_shared      musl no  glibc yes

I've posted the corresponding part from config.log below. It fails
because musl doesn't define PTHREAD_MUTEX_ROBUST_NP (glibc does). And
apr uses PTHREAD_MUTEX_ROBUST_NP. It means that I should set
apr_cv_mutex_robust_shared=no when cross-compiling this apr, I suppose
:)

configure:25459: checking for robust cross-process mutex support
configure:25500: gcc -o conftest -g -O2 -DLINUX -D_REENTRANT -D_GNU_SOURCE  conftest.c -lpthread >&5
conftest.c: In function 'main':
conftest.c:197:47: error: 'PTHREAD_MUTEX_ROBUST_NP' undeclared (first use in this function)
     if (pthread_mutexattr_setrobust_np(&attr, PTHREAD_MUTEX_ROBUST_NP))
                                               ^
conftest.c:197:47: note: each undeclared identifier is reported only once for each function it appears in
configure:25500: $? = 1
configure: program exited with status 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define __EXTENSIONS__ 1
| #define _ALL_SOURCE 1
| #define _GNU_SOURCE 1
| #define _POSIX_PTHREAD_SEMANTICS 1
| #define _TANDEM_SOURCE 1
| #define HAVE_DLFCN_H 1
| #define LT_OBJDIR ".libs/"
| #define HAVE_ATOMIC_BUILTINS 1
| #define HAVE_PTHREAD_H 1
| #define HAVE_PTHREAD_H 1
| #define HAVE_PTHREAD_MUTEX_RECURSIVE 1
| #define HAVE_PTHREAD_KEY_DELETE 1
| #define HAVE_PTHREAD_RWLOCK_INIT 1
| #define HAVE_PTHREAD_ATTR_SETGUARDSIZE 1
| #define HAVE_PTHREAD_RWLOCKS 1
| #define HAVE_SCHED_H 1
| #define HAVE_SCHED_YIELD 1
| #define HAVE_GETHOSTBYNAME_R 1
| #define HAVE_GETHOSTBYADDR_R 1
| #define HAVE_GETSERVBYNAME_R 1
| #define HAVE_SIGSUSPEND 1
| #define HAVE_SIGWAIT 1
| #define HAVE_POLL 1
| #define HAVE_EPOLL 1
| #define HAVE_EPOLL_CREATE1 1
| #define HAVE_DUP3 1
| #define HAVE_ACCEPT4 1
| #define HAVE_SOCK_CLOEXEC 1
| #define HAVE_FDATASYNC 1
| #define HAVE_EPOLL_CREATE1 1
| #define HAVE_DUP3 1
| #define HAVE_ACCEPT4 1
| #define HAVE_SOCK_CLOEXEC 1
| #define HAVE_GETPWNAM_R 1
| #define HAVE_GETPWUID_R 1
| #define HAVE_GETGRNAM_R 1
| #define HAVE_GETGRGID_R 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_MMAN_H 1
| #define HAVE_SYS_IPC_H 1
| #define HAVE_SYS_SHM_H 1
| #define HAVE_SYS_FILE_H 1
| #define HAVE_MMAP 1
| #define HAVE_MUNMAP 1
| #define HAVE_SHM_OPEN 1
| #define HAVE_SHM_UNLINK 1
| #define HAVE_SHMGET 1
| #define HAVE_SHMAT 1
| #define HAVE_SHMDT 1
| #define HAVE_SHMCTL 1
| #define HAVE_MAP_ANON 1
| #define anonymous shared memory allocation method 1
| #define USE_SHMEM_MMAP_ANON 1
| #define namebased memory allocation method 1
| #define USE_SHMEM_SHMGET 1
| #define HAVE_ALLOCA_H 1
| #define HAVE_ALLOCA 1
| #define HAVE_CALLOC 1
| #define HAVE_SETSID 1
| #define HAVE_GETENV 1
| #define HAVE_PUTENV 1
| #define HAVE_SETENV 1
| #define HAVE_UNSETENV 1
| #define HAVE_WRITEV 1
| #define HAVE_GETIFADDRS 1
| #define HAVE_UTIME 1
| #define HAVE_UTIMES 1
| #define HAVE_SETRLIMIT 1
| #define HAVE_GETRLIMIT 1
| #define HAVE_SENDFILE 1
| #define HAVE_SIGACTION 1
| #define HAVE_DECL_SYS_SIGLIST 0
| #define HAVE_FORK 1
| #define HAVE_STRERROR_R 1
| #define STRERROR_R_RC_INT 1
| #define HAVE_MMAP 1
| #define HAVE_MEMMOVE 1
| #define HAVE_GETPASS 1
| #define HAVE_GMTIME_R 1
| #define HAVE_LOCALTIME_R 1
| #define HAVE_MKSTEMP 1
| #define STDC_HEADERS 1
| #define HAVE_CRYPT_H 1
| #define HAVE_CTYPE_H 1
| #define HAVE_DIRENT_H 1
| #define HAVE_DLFCN_H 1
| #define HAVE_ERRNO_H 1
| #define HAVE_FCNTL_H 1
| #define HAVE_GRP_H 1
| #define HAVE_LIMITS_H 1
| #define HAVE_MALLOC_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_NETDB_H 1
| #define HAVE_POLL_H 1
| #define HAVE_PWD_H 1
| #define HAVE_SEMAPHORE_H 1
| #define HAVE_SIGNAL_H 1
| #define HAVE_STDARG_H 1
| #define HAVE_STDDEF_H 1
| #define HAVE_STDIO_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_TERMIOS_H 1
| #define HAVE_TIME_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_ARPA_INET_H 1
| #define HAVE_NETINET_IN_H 1
| #define HAVE_SYS_FILE_H 1
| #define HAVE_SYS_IOCTL_H 1
| #define HAVE_SYS_MMAN_H 1
| #define HAVE_SYS_PARAM_H 1
| #define HAVE_SYS_POLL_H 1
| #define HAVE_SYS_RESOURCE_H 1
| #define HAVE_SYS_SELECT_H 1
| #define HAVE_SYS_SEM_H 1
| #define HAVE_SYS_SENDFILE_H 1
| #define HAVE_SYS_SIGNAL_H 1
| #define HAVE_SYS_SOCKET_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_SYS_TIME_H 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_UIO_H 1
| #define HAVE_SYS_UN_H 1
| #define HAVE_SYS_WAIT_H 1
| #define HAVE_NETINET_TCP_H 1
| #define SETPGRP_VOID 1
| #define HAVE_SOCKLEN_T 1
| #define SIZEOF_VOIDP 8
| #define SIZEOF_CHAR 1
| #define SIZEOF_INT 4
| #define SIZEOF_LONG 8
| #define SIZEOF_SHORT 2
| #define SIZEOF_LONG_LONG 8
| #define SIZEOF_PID_T 4
| #define SIZEOF_SSIZE_T 8
| #define SIZEOF_SIZE_T 8
| #define SIZEOF_OFF_T 8
| #define SIZEOF_INO_T 8
| #define SIZEOF_STRUCT_IOVEC 16
| #define HAVE_STRNCASECMP 1
| #define HAVE_STRCASECMP 1
| #define HAVE_STRDUP 1
| #define HAVE_STRSTR 1
| #define HAVE_MEMCHR 1
| #define APR_INT64_STRFN strtol
| #define APR_OFF_T_STRFN strtol
| #define DSO_USE_DLFCN 1
| #define HAVE_WAITPID 1
| #define HAVE_VLA 1
| #define HAVE_SEMGET 1
| #define HAVE_SEMCTL 1
| #define HAVE_FLOCK 1
| #define HAVE_SEMAPHORE_H 1
| #define HAVE_SEM_CLOSE 1
| #define HAVE_SEM_UNLINK 1
| #define HAVE_SEM_POST 1
| #define HAVE_SEM_WAIT 1
| #define HAVE_LOCK_EX 1
| #define HAVE_F_SETLK 1
| #define HAVE_SEM_UNDO 1
| #define HAVE_POLLIN 1
| #define HAVE_PTHREAD_PROCESS_SHARED 1
| #define HAVE_PTHREAD_MUTEXATTR_SETPSHARED 1
| /* end confdefs.h.  */
|
| #include <sys/types.h>
| #include <pthread.h>
| #include <stdlib.h>
|
| int main(int argc, char **argv)
| {
|     pthread_mutex_t mutex;
|     pthread_mutexattr_t attr;
|
|     if (pthread_mutexattr_init(&attr))
|         exit(1);
|     if (pthread_mutexattr_setpshared(&attr, PTHREAD_PROCESS_SHARED))
|         exit(2);
|     if (pthread_mutexattr_setrobust_np(&attr, PTHREAD_MUTEX_ROBUST_NP))
|         exit(3);
|     if (pthread_mutexattr_setprotocol(&attr, PTHREAD_PRIO_INHERIT))
|         exit(4);
|     if (pthread_mutex_init(&mutex, &attr))
|         exit(5);
|     if (pthread_mutexattr_destroy(&attr))
|         exit(6);
|     if (pthread_mutex_destroy(&mutex))
|         exit(7);
|
|     exit(0);
| }
configure:25510: result: no
configure:25895: result: decision on apr_lock implementation method... SysV IPC semget()

Re: Robust shared mutexes?

[Szabolcs Nagy]

* Sebastian Kemper <sebastian_ml@gmx.net> [2016-11-27 11:54:34 +0100]:
> On Sun, Nov 27, 2016 at 12:01:10AM +0100, Szabolcs Nagy wrote:
> > * Rich Felker <dalias@libc.org> [2016-11-26 17:56:18 -0500]:
> > > On Sat, Nov 26, 2016 at 11:51:05PM +0100, Sebastian Kemper wrote:
> > > > 
> > > > http://lists.openembedded.org/pipermail/openembedded-core/2016-March/119214.html
> > > > 
> > > > It says musl doesn't have process shared mutexes so one should set
> > > > apr_cv_process_shared_works=no. I take it that is correct?
> > > 
> > > No, it's incorrect and I have no idea where that idea came from. I'll
> > > ask Khem.
> > > 
> > 
> > apr might care about sharing mutexes across i386 vs x86_64 ?
> > 
> > that does not work (glibc ditto)
> 
> Hello Szabolcs, list,
> 
> I installed a Gentoo musl-1.1.15 x86_64 chroot on my computer. Then I
> ran ./configure in apr-1.5.2 in the musl chroot and also outside the
> chroot in a glibc-2.22 environment.
> 
> The outcome was the same except for apr_cv_mutex_robust_shared:
> 
> ac_cv_func_setpgrp_void         musl yes glibc yes
> ac_cv_file__dev_zero            musl yes glibc yes
> apr_cv_tcp_nodelay_with_cork    musl yes glibc yes
> apr_cv_mutex_recursive          musl yes glibc yes
> ac_cv_func_pthread_rwlock_init  musl yes glibc yes
> apr_cv_type_rwlock_t=yes        musl yes glibc yes
> apr_cv_process_shared_works     musl yes glibc yes
> apr_cv_mutex_robust_shared      musl no  glibc yes
> 
> I've posted the corresponding part from config.log below. It fails
> because musl doesn't define PTHREAD_MUTEX_ROBUST_NP (glibc does). And
> apr uses PTHREAD_MUTEX_ROBUST_NP. It means that I should set
> apr_cv_mutex_robust_shared=no when cross-compiling this apr, I suppose
> :)

the standard name is PTHREAD_MUTEX_ROBUST since posix2008,
so this is an apr bug.

> configure:25459: checking for robust cross-process mutex support
> configure:25500: gcc -o conftest -g -O2 -DLINUX -D_REENTRANT -D_GNU_SOURCE  conftest.c -lpthread >&5
> conftest.c: In function 'main':
> conftest.c:197:47: error: 'PTHREAD_MUTEX_ROBUST_NP' undeclared (first use in this function)
>      if (pthread_mutexattr_setrobust_np(&attr, PTHREAD_MUTEX_ROBUST_NP))
>                                                ^

i think they should use the standard name and provide
their own definition on legacy systems

#ifndef PTHREAD_MUTEX_ROBUST
#define PTHREAD_MUTEX_ROBUST PTHREAD_MUTEX_ROBUST_NP
#endif

Re: Robust shared mutexes?

[Alexander Monakov]

On Sun, 27 Nov 2016, Sebastian Kemper wrote:
> I've posted the corresponding part from config.log below. It fails
> because musl doesn't define PTHREAD_MUTEX_ROBUST_NP (glibc does). And
> apr uses PTHREAD_MUTEX_ROBUST_NP. It means that I should set
> apr_cv_mutex_robust_shared=no when cross-compiling this apr, I suppose
> :)
> 
> configure:25459: checking for robust cross-process mutex support
> configure:25500: gcc -o conftest -g -O2 -DLINUX -D_REENTRANT -D_GNU_SOURCE  conftest.c -lpthread >&5
> conftest.c: In function 'main':
> conftest.c:197:47: error: 'PTHREAD_MUTEX_ROBUST_NP' undeclared (first use in this function)
>      if (pthread_mutexattr_setrobust_np(&attr, PTHREAD_MUTEX_ROBUST_NP))

This configure check is very old and predates standartization of robust mutexes
in POSIX 2008: http://svn.apache.org/viewvc?view=revision&revision=382030

Consequently, APR uses _np interfaces for robust mutexes, so the their uses in
locks/unix/proc_mutex.c would need to be fixed together with this configure
check.

But I don't understand their use of robust mutexes, in that file
proc_mutex_proc_pthread_acquire just calls pthread_mutex_consistent_np without
any sort of callback or indicating it to the caller via the return value.

Alexander

Re: Robust shared mutexes?

[Sebastian Kemper]

Hello Szabolcs and Alexander,

Thank you very much for your remarks! For now I've set
apr_cv_mutex_robust_shared=no in the Makefile and added a comment as to
the reason why so this can be revisited later when apr gets an update.

Kind regards,
Sebastian

Re: Robust shared mutexes?

[Khem Raj]

> On Nov 26, 2016, at 2:56 PM, Rich Felker <dalias@libc.org> wrote:
> 
> On Sat, Nov 26, 2016 at 11:51:05PM +0100, Sebastian Kemper wrote:
>> On Sat, Nov 26, 2016 at 05:24:43PM -0500, Rich Felker wrote:
>>> On Sat, Nov 26, 2016 at 10:49:44PM +0100, Sebastian Kemper wrote:
>>>> Hello all,
>>>> 
>>>> I'm cross-compiling for OpenWRT/LEDE and have this variable
>>>> apr_cv_mutex_robust_shared. Should I set it to yes or no with musl? I've
>>>> searched around but found conflicting infos. One post said there's no
>>>> shared mutex support in musl
>>> 
>>> Do you have a link for that? If there's incorrect information I'd like
>>> to reply and see if it can be corrected.
>> 
>> Hello Rich,
>> 
>> Thank you very much for the reply!
>> 
>> I looked for the link and it turns out it was an error on my part. The
>> post wasn't referring to robust shared mutexes. It was regarding process
>> shared mutexes
>> 
>> http://lists.openembedded.org/pipermail/openembedded-core/2016-March/119214.html
>> 
>> It says musl doesn't have process shared mutexes so one should set
>> apr_cv_process_shared_works=no. I take it that is correct?
> 
> No, it's incorrect and I have no idea where that idea came from. I'll
> ask Khem.
> 

IIRC it was not musl but papering over apr specific issue. I never got time to really dig in
to root cause it.

Re: Robust shared mutexes?

[Rich Felker]

On Mon, Nov 28, 2016 at 01:36:50PM -0800, Khem Raj wrote:
> 
> > On Nov 26, 2016, at 2:56 PM, Rich Felker <dalias@libc.org> wrote:
> > 
> > On Sat, Nov 26, 2016 at 11:51:05PM +0100, Sebastian Kemper wrote:
> >> On Sat, Nov 26, 2016 at 05:24:43PM -0500, Rich Felker wrote:
> >>> On Sat, Nov 26, 2016 at 10:49:44PM +0100, Sebastian Kemper wrote:
> >>>> Hello all,
> >>>> 
> >>>> I'm cross-compiling for OpenWRT/LEDE and have this variable
> >>>> apr_cv_mutex_robust_shared. Should I set it to yes or no with musl? I've
> >>>> searched around but found conflicting infos. One post said there's no
> >>>> shared mutex support in musl
> >>> 
> >>> Do you have a link for that? If there's incorrect information I'd like
> >>> to reply and see if it can be corrected.
> >> 
> >> Hello Rich,
> >> 
> >> Thank you very much for the reply!
> >> 
> >> I looked for the link and it turns out it was an error on my part. The
> >> post wasn't referring to robust shared mutexes. It was regarding process
> >> shared mutexes
> >> 
> >> http://lists.openembedded.org/pipermail/openembedded-core/2016-March/119214.html
> >> 
> >> It says musl doesn't have process shared mutexes so one should set
> >> apr_cv_process_shared_works=no. I take it that is correct?
> > 
> > No, it's incorrect and I have no idea where that idea came from. I'll
> > ask Khem.
> > 
> 
> IIRC it was not musl but papering over apr specific issue. I never got time to really dig in
> to root cause it.

Indeed, that's what it seems to be here too. They don't support the
standard API, only some ancient glibc _NP version of it, and they
don't even do anything to handle the case of ownerdied correctly...

Rich