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 09:07:39 GMT
On Fri, Mar 31, 2017 at 4:21 AM, William A Rowe Jr <wrowe@rowe-clan.net> wrote:
> So almost two decades later, this is still odd.
>
> 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

What's odd?

My understanding is that SHMEM_SHMGET and MMAP_ANON are not mutually
exclusive because the former is ENOTIMPL in apr_shm_create when
filename is NULL (i.e. anonymous SHM), hence the latter would be used.

Regarding USE_SYSVSEM_SERIALIZE vs PTHREAD_SERIALIZE, the former is
for proc_mutex whereas the latter is for thread_mutex, so I think they
don't collide either.

Mime
View raw message