Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <51F27B3D-DB20-431F-9CB8-1BAA746FF71C@jaguNET.com>
References: <CACsi251LG4O7NBmTx52pyLfYseK+-C9Dm7eXjNTvOLagcKYvUw@mail.gmail.com>
 <14A97192-B5DA-46CD-AD86-8A7317648BD7@apache.org> <51F27B3D-DB20-431F-9CB8-1BAA746FF71C@jaguNET.com>
From: William A Rowe Jr <wrowe@rowe-clan.net>
Date: Fri, 31 Mar 2017 14:38:13 -0500
Message-ID: <CACsi252CA0RKz_GE1fFe9=bGpbSKmKSRhbvK19+epT8bWDtVEA@mail.gmail.com>
Subject: Re: Default Linux mutex method
To: Jim Jagielski <jim@jagunet.com>
Cc: Nick Kew <niq@apache.org>, APR Developer List <dev@apr.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
archived-at: Fri, 31 Mar 2017 19:38:20 -0000

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.
http://httpd.apache.org/docs/2.0/misc/perf-tuning.html

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=E2=80=99ve just (finally) got the toolchain to build & test this on Mac=
OS,
> and I=E2=80=99ve got identical APR_USE results there.  Perhaps our build =
logic
> really isn=E2=80=99t 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.