apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: Default Linux mutex method
Date Fri, 31 Mar 2017 19:38:13 GMT
On Fri, Mar 31, 2017 at 10:22 AM, Jim Jagielski <jim@jagunet.com> wrote:
> Reading the configure.in file, it looks like we are due
> for some updates for the 21st century:
> # See which lock mechanism we'll select by default on this system.
> # The last APR_DECIDE to execute sets the default.
> # At this stage, we match the ordering in Apache 1.3
> # which is (highest to lowest): sysvsem -> fcntl -> flock.
> # POSIX semaphores and cross-process pthread mutexes are not
> # used by default since they have less desirable behaviour when
> # e.g. a process holding the mutex segfaults.

LOL - it was re-reading Roy's 1.2/1.3 timeframe cautions about
avoiding sysvsem that brought me back to this topic, actually.

The pthread mutexes certainly should be cleaned up on a segv.
The sysvsem mutexes will not be cleaned up, just found another
annoyed user on Wednesday which reminded me to look at this.

Are modern pthread mutexes sufficiently reliable this decade?

On Fri, Mar 31, 2017 at 9:58 AM, Nick Kew <niq@apache.org> wrote:
> 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?

locks/unix/proc_mutex.c is the sole apr consumer of these flags, see
line 1177 within proc_mutex_choose_method(). Posix is dead last,
followed by pthread, fcntl, sysv and file in ascending priority. Without
changing the autoconf logic in the slightest, I would think we aught to
simply flip the prioritization of pthread and sysv.

But we do need BSD/Solaris/OSX feedback here.

View raw message