|
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.