Re: Default Linux mutex method

> On 31 Mar 2017, at 03:21, William A Rowe Jr 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

Re: apr_file_copy with APR_FILE_SOURCE_PERMS not copying permissions if destination already exists

> On 30 Mar 2017, at 15:59, William A Rowe Jr wrote: > > I'd suggest we treat it as a bug, change the behavior accordingly in 1.6.0, > and @bug the API to indicate the old vs new behavior. Thoughts? On reflection, +1 to all that. — Nick Kew

Re: Default Linux mutex method

> On Mar 30, 2017, at 10:21 PM, William A Rowe Jr wrote: > > > 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. > Which is faster?

Re: apr_file_copy with APR_FILE_SOURCE_PERMS not copying permissions if destination already exists

On Fri, Mar 31, 2017 at 10:04 AM, Nick Kew wrote: > >> On 30 Mar 2017, at 15:59, William A Rowe Jr wrote: >> >> I'd suggest we treat it as a bug, change the behavior accordingly in 1.6.0, >> and @bug the API to indicate the old vs new behavior. Thoughts? > >

Re: Default Linux mutex method

On Fri, Mar 31, 2017 at 10:22 AM, Jim Jagielski 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. >

fdatasync on mac

fdatasync on Mac is a mess. What I’ve been hacking at is described in https://bugs.freedesktop.org/show_bug.cgi?id=74873 where they face the same issue. My inclination is to steer clear of this mess. We can disable fdatasync on mac with a simple patch: $ svn diff Index: configure.in

Re: Default Linux mutex method

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):

No timed lock on MacOS

Just (finally) got the toolchain up on the new macbook[1], so I’m testing there. Getting a failure in testprocmutex: there is no timedlock. ./testall -v testprocmutex testprocmutex : \default_timedlock() not implemented,-flock_timedlock() not implemented,|sysvsem_timedlock() not

Re: No timed lock on MacOS

Nobody has added it yet in 1.6+ I've no idea what platforms are supported/implemented... > On Mar 31, 2017, at 11:49 AM, Nick Kew wrote: > > Just (finally) got the toolchain up on the new macbook[1], so I’m > testing there. Getting a failure in testprocmutex: there is no

Re: No timed lock on MacOS

I *think* it's just supported right now for platforms that use pthread mutexes > On Mar 31, 2017, at 12:27 PM, Jim Jagielski wrote: > > Nobody has added it yet in 1.6+ > > I've no idea what platforms are supported/implemented... > >> On Mar 31, 2017, at 11:49 AM, Nick Kew