Am 01.04.2017 um 19:02 schrieb Yann Ylavic:
On Fri, Mar 31, 2017 at 4:58 PM, Nick Kew <n...@apache.org> wrote:
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?
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?).
First current autodetect results for Solaris 8 (ancient) and 10 (still
in use). I don't have 11 results easily at hand but could provide them:
Solaris 8
#define APR_USE_SHMEM_MMAP_TMP 0
#define APR_USE_SHMEM_MMAP_SHM 0
#define APR_USE_SHMEM_MMAP_ZERO 0
#define APR_USE_SHMEM_SHMGET_ANON 0
#define APR_USE_SHMEM_SHMGET 1
#define APR_USE_SHMEM_MMAP_ANON 1
#define APR_USE_SHMEM_BEOS 0
#define APR_USE_FLOCK_SERIALIZE 0
#define APR_USE_SYSVSEM_SERIALIZE 0
#define APR_USE_POSIXSEM_SERIALIZE 0
#define APR_USE_FCNTL_SERIALIZE 1
#define APR_USE_PROC_PTHREAD_SERIALIZE 0
#define APR_USE_PTHREAD_SERIALIZE 1
Solaris 10:
the same except for
#define APR_USE_FCNTL_SERIALIZE 0 (instead of 1)
#define APR_USE_PROC_PTHREAD_SERIALIZE 1 (instead of 0)
Both versions detect/set HAVE_PTHREAD_MUTEX_ROBUST during configure.
I don't have first hand knowledge, but the topic came up a couple of
times. There's this old conversation between Joe and Jeff:
http://marc.info/?t=108720981900003&r=1&w=2
Then we have included 5 years later since APR 1.3.10:
http://svn.apache.org/viewvc?rev=881301&view=rev
From the log:
Solaris 10 or later: Use pthread by default for cross-process mutex
instead of fcntl; the latter is not thread-aware, leading to EDEADLK
failures with some multi-threaded, multi-process applications.
Proper recovery after a crash of the mutex owner was tested on Solaris
10 U5 and OpenSolaris 2009.06. Earlier Solaris versions weren't tested,
and there were reports in httpd-land long ago about failures to recover
the mutex.
The list discussion (triggered by Jim originally not restricted to
Solaris) that lead to this decision can be found here:
http://marc.info/?t=123843657300003&r=1&w=2
It contains some more details.
I do not know anything more recent then contained there.
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
(when HAVE_PTHREAD_MUTEX_ROBUST).
Regards,
Yann.
[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=21322#c18
[2] https://bz.apache.org/bugzilla/show_bug.cgi?id=49504
Regards,
Rainer
