> On 31 Mar 2017, at 03:21, William A Rowe Jr <wr...@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? > 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. Probably applies more widely than just Linux. But might a general fix risk breaking some minority Unix platform or cross-compile? > Do we want to fix this in the 1.6.0 release? How confident are you of not breaking anything with a fix? — Nick Kew
