Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.20.13.1611271424270.2229@monopod.intra.ispras.ru>
Date: Sun, 27 Nov 2016 14:51:08 +0300 (MSK)
From: Alexander Monakov <amonakov@...ras.ru>
To: Sebastian Kemper <sebastian_ml@....net>
cc: musl@...ts.openwall.com, Szabolcs Nagy <nsz@...t70.net>
Subject: Re: Robust shared mutexes?

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

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.