apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <ylavic....@gmail.com>
Subject Re: Default Linux mutex method
Date Sat, 01 Apr 2017 17:02:02 GMT
On Fri, Mar 31, 2017 at 4:58 PM, Nick Kew <niq@apache.org> wrote:
>> On 31 Mar 2017, at 03:21, William A Rowe Jr <wrowe@rowe-clan.net> wrote:
>> So almost two decades later, this is still odd.
> Is this a reference to some technical discussion on the subject you recollect?
> Have you verified that all APR_USE_*_SERIALIZE are mutually exclusive,
> or could it be that we use both in different contexts, perhaps for a valid reason?
>> apr.h:#define APR_USE_SHMEM_MMAP_TMP     0
>> apr.h:#define APR_USE_SHMEM_MMAP_SHM     0
>> apr.h:#define APR_USE_SHMEM_MMAP_ZERO    0
>> apr.h:#define APR_USE_SHMEM_SHMGET_ANON  0
>> apr.h:#define APR_USE_SHMEM_SHMGET       1
>> apr.h:#define APR_USE_SHMEM_MMAP_ANON    1
>> apr.h:#define APR_USE_SHMEM_BEOS         0
>> apr.h:#define APR_USE_FLOCK_SERIALIZE           0
>> apr.h:#define APR_USE_SYSVSEM_SERIALIZE         1
>> apr.h:#define APR_USE_POSIXSEM_SERIALIZE        0
>> apr.h:#define APR_USE_FCNTL_SERIALIZE           0
>> apr.h:#define APR_USE_PROC_PTHREAD_SERIALIZE    0
>> apr.h:#define APR_USE_PTHREAD_SERIALIZE         1
> I’ve just (finally) got the toolchain to build & test this on MacOS,
> and I’ve got identical APR_USE results there.  Perhaps our build logic
> really isn’t doing anything very smart at all?

Looks good to me (as said in the other message), nothing mutually
exclusive AFAICT.

>> SYSVSEM > PTHREAD in the code logic, so we are still using
>> sysv semaphores with all their defects over the choice of pthread
>> mutexes where both are supported on Linux.

The main defect being the leak of an (limited) IPC entry when httpd
does not shutdown cleanly, and that it's slower than pthreads, though
it's hardly measurable probably.

> Probably applies more widely than just Linux.  But might a general fix
> risk breaking some minority Unix platform or cross-compile?

SYSVSEM are robust (can be recovered after a process owning one
crashes), so the switch to PTHREAD should depend on
HAVE_PTHREAD_MUTEX_ROBUST only I think (which should be the case for
Linux and Solaris at least).

Solaris had issue a while ago ([1], which seems to be the "why" for
prefering SYSVSEM over some shared-pthread implementations), but it's
probably addressed now (Rainer maybe?).

>> Do we want to fix this in the 1.6.0 release?
> How confident are you of not breaking anything with a fix?

The only proc_pthread issue I can think of is [2] (long thread), which
we addressed in both 1.5.x and 1.6.x, so +1 for me for the switch


[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=21322#c18
[2] https://bz.apache.org/bugzilla/show_bug.cgi?id=49504

View raw message