You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Yann Ylavic <yl...@gmail.com> on 2017/04/04 20:29:36 UTC
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c test/testlock.c
On Tue, Apr 4, 2017 at 3:09 PM, <ji...@apache.org> wrote:
> Author: jim
> Date: Tue Apr 4 13:09:02 2017
> New Revision: 1790105
>
> URL: http://svn.apache.org/viewvc?rev=1790105&view=rev
> Log:
> Add in our own pthread_mutex_timedlock impl for those OSs, like
> osx/macos that don't have it. Be a bit more generous in the test
>
> Added:
> apr/apr/branches/1.6.x/locks/unix/misc.c
> Modified:
> apr/apr/branches/1.6.x/locks/unix/proc_mutex.c
> apr/apr/branches/1.6.x/locks/unix/thread_mutex.c
> apr/apr/branches/1.6.x/test/testlock.c
>
> Added: apr/apr/branches/1.6.x/locks/unix/misc.c
> URL: http://svn.apache.org/viewvc/apr/apr/branches/1.6.x/locks/unix/misc.c?rev=1790105&view=auto
> ==============================================================================
> --- apr/apr/branches/1.6.x/locks/unix/misc.c (added)
> +++ apr/apr/branches/1.6.x/locks/unix/misc.c Tue Apr 4 13:09:02 2017
[]
> +
> +#ifndef HAVE_PTHREAD_MUTEX_TIMEDLOCK
> +extern int pthread_mutex_timedlock(pthread_mutex_t *mutex, const struct timespec *abs_timeout);
> +#define SLEEP_TIME_NS 10000000
Admittedly depending on the use case, but 100ms can be very long and
also not very friendly w.r.t. wakeups (for a relatively small timeout
of 10s, that'd be 100 spurious schedules).
I'm not a big fan of the "sleep" fallback implementation.
>
> Modified: apr/apr/branches/1.6.x/locks/unix/thread_mutex.c
> URL: http://svn.apache.org/viewvc/apr/apr/branches/1.6.x/locks/unix/thread_mutex.c?rev=1790105&r1=1790104&r2=1790105&view=diff
> ==============================================================================
> --- apr/apr/branches/1.6.x/locks/unix/thread_mutex.c (original)
> +++ apr/apr/branches/1.6.x/locks/unix/thread_mutex.c Tue Apr 4 13:09:02 2017
> @@ -77,19 +77,6 @@ APR_DECLARE(apr_status_t) apr_thread_mut
> return rv;
> }
>
> -#ifndef HAVE_PTHREAD_MUTEX_TIMEDLOCK
> - if (flags & APR_THREAD_MUTEX_TIMED) {
> - rv = apr_thread_cond_create(&new_mutex->cond, pool);
> - if (rv) {
> -#ifdef HAVE_ZOS_PTHREADS
> - rv = errno;
> -#endif
> - pthread_mutex_destroy(&new_mutex->mutex);
> - return rv;
> - }
> - }
> -#endif
Why don't we keep the condvar implementation for thread mutexes at least?
I don't see many drawbacks compared to the "sleep" implementation..
For proc mutexes, maybe we could use a pipe (anon) or an USD (named),
and then read/write/poll to have accurate and precise timeout/waiting
time.
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c
test/testlock.c
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Apr 5, 2017, at 6:42 AM, Branko Čibej <br...@apache.org> wrote:
>
> On 05.04.2017 12:39, Yann Ylavic wrote:
>> On Wed, Apr 5, 2017 at 12:27 PM, Branko Čibej <br...@apache.org> wrote:
>>> On 05.04.2017 12:19, Yann Ylavic wrote:
>>>> On Tue, Apr 4, 2017 at 10:57 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>>>>>> On Apr 4, 2017, at 4:29 PM, Yann Ylavic <yl...@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>> I'm not a big fan of the "sleep" fallback implementation.
>>>>>>
>>>>> Feel free to replace it with something better.
>>>> Would an implementation based on a pipe (hence two FDs per mutex) be acceptable?
>>> The default open-file limit on the Mac is a paltry 256, I'm not sure
>>> it'd be a good idea for APR to suddenly start using up file descriptors
>>> for timed waits on mutexes.
>> Yes, that was my fear...
>>
>>> Couldn't we use a condition variable for this?
>> We can for thread-mutexes (was the case before this commit), but not
>> for proc-mutexes since OSX also lacks pshared condvars (i.e.
>> PTHREAD_CONDATTR_SETPSHARED).
>
> Not according to the header files. The declaration is there, available
> since OSX 10.4 and iOS 2.0, which I'd say means it's pretty much
> available always.
>
Hmmm.... last I checked, the pthread_condattr_setpshared() was considered
buggy under OSX (and defined but not even in the man pages) and
was avoided. However, looking at various repos out there, that
may no longer be the case as of 10.7/10.8...
+1 for trying to use it
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c test/testlock.c
Posted by Yann Ylavic <yl...@gmail.com>.
On Fri, Apr 7, 2017 at 1:17 AM, Branko Čibej <br...@apache.org> wrote:
>
> brane@zulu:~/src/apr/build/trunk$ grep HAVE_PTHREAD_CONDATTR_SETPSHARED ./include/arch/unix/apr_private.h
> #define HAVE_PTHREAD_CONDATTR_SETPSHARED 1
>
>
> Looks good?
Yes, looks good, the condvar fallback for proc_pthread mutexes seems
to work on OSX, regardless of which process/thread owns the mutex...
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c
test/testlock.c
Posted by Branko Čibej <br...@apache.org>.
On 06.04.2017 21:05, Yann Ylavic wrote:
> On Thu, Apr 6, 2017 at 9:01 PM, Branko \u010cibej <br...@apache.org> wrote:
>> On 06.04.2017 20:49, Yann Ylavic wrote:
>>> On Thu, Apr 6, 2017 at 1:40 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>>>> apr-trunk (r1790379):
>>>> % ./testall -v testprocmutex
>>>> testprocmutex : -Line 189: Locks don't appear to work with timedlock
>>>> -flock_timedlock() not implemented,/Line 189: Locks don't appear to work with timedlock
>>>> -Line 189: Locks don't appear to work with timedlock
>>>> -fcntl_timedlock() not implemented,-Line 133: create the mutex
>>>> /default_timed_timedlock() not implemented,-Line 172: Default timed timedlock not implemented
>>>> FAILED 4 of 6
>>>> Failed Tests Total Fail Failed %
>>>> ===================================================
>>>> testprocmutex 6 4 66.67%
>>>>
>>>> apr-1.6 (r1790305):
>>>> % ./testall -v testprocmutex
>>>> testprocmutex : -flock_timedlock() not implemented,-Line 194: Locks don't appear to work with timedlock
>>>> -fcntl_timedlock() not implemented,FAILED 1 of 6
>>>> Failed Tests Total Fail Failed %
>>>> ===================================================
>>>> testprocmutex 6 1 16.67%
>>>>
>>>> we seem to be going backwards (apr-trunk includes the fallback)
>>>> since now we lost default_timed_timedlock()
>>> I tried to not modify the other (non PROC_PTHREAD) mechanisms normally.
>>> Could it be, e.g., r1790303 (which is not in 1.6.x either)?
>>>
>>> Anyway, I just commited another fallback (r1790436), could you please
>>> test this version on OSX?
>>> If pshared mutex+cond still do not work as expected on OSX, maybe we
>>> could un-configure it (i.e. ac_have_pthread_condattr_setpshared="no")
>>> and let it fall through the new generic fallback...
>> This is on OSX 10.11.6 with clang from XCode 8.2.1.
> Thanks Brane, can you confirm (on trunk) that
> HAVE_PTHREAD_CONDATTR_SETPSHARED is defined, hence it's working as
> expected?
brane@zulu:~/src/apr/build/trunk$ grep HAVE_PTHREAD_CONDATTR_SETPSHARED ./include/arch/unix/apr_private.h
#define HAVE_PTHREAD_CONDATTR_SETPSHARED 1
Looks good?
-- Brane
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c test/testlock.c
Posted by Yann Ylavic <yl...@gmail.com>.
On Thu, Apr 6, 2017 at 9:01 PM, Branko Čibej <br...@apache.org> wrote:
> On 06.04.2017 20:49, Yann Ylavic wrote:
>> On Thu, Apr 6, 2017 at 1:40 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>>> apr-trunk (r1790379):
>>> % ./testall -v testprocmutex
>>> testprocmutex : -Line 189: Locks don't appear to work with timedlock
>>> -flock_timedlock() not implemented,/Line 189: Locks don't appear to work with timedlock
>>> -Line 189: Locks don't appear to work with timedlock
>>> -fcntl_timedlock() not implemented,-Line 133: create the mutex
>>> /default_timed_timedlock() not implemented,-Line 172: Default timed timedlock not implemented
>>> FAILED 4 of 6
>>> Failed Tests Total Fail Failed %
>>> ===================================================
>>> testprocmutex 6 4 66.67%
>>>
>>> apr-1.6 (r1790305):
>>> % ./testall -v testprocmutex
>>> testprocmutex : -flock_timedlock() not implemented,-Line 194: Locks don't appear to work with timedlock
>>> -fcntl_timedlock() not implemented,FAILED 1 of 6
>>> Failed Tests Total Fail Failed %
>>> ===================================================
>>> testprocmutex 6 1 16.67%
>>>
>>> we seem to be going backwards (apr-trunk includes the fallback)
>>> since now we lost default_timed_timedlock()
>> I tried to not modify the other (non PROC_PTHREAD) mechanisms normally.
>> Could it be, e.g., r1790303 (which is not in 1.6.x either)?
>>
>> Anyway, I just commited another fallback (r1790436), could you please
>> test this version on OSX?
>> If pshared mutex+cond still do not work as expected on OSX, maybe we
>> could un-configure it (i.e. ac_have_pthread_condattr_setpshared="no")
>> and let it fall through the new generic fallback...
>
> This is on OSX 10.11.6 with clang from XCode 8.2.1.
Thanks Brane, can you confirm (on trunk) that
HAVE_PTHREAD_CONDATTR_SETPSHARED is defined, hence it's working as
expected?
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c
test/testlock.c
Posted by Branko Čibej <br...@apache.org>.
On 06.04.2017 20:49, Yann Ylavic wrote:
> On Thu, Apr 6, 2017 at 1:40 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>> apr-trunk (r1790379):
>> % ./testall -v testprocmutex
>> testprocmutex : -Line 189: Locks don't appear to work with timedlock
>> -flock_timedlock() not implemented,/Line 189: Locks don't appear to work with timedlock
>> -Line 189: Locks don't appear to work with timedlock
>> -fcntl_timedlock() not implemented,-Line 133: create the mutex
>> /default_timed_timedlock() not implemented,-Line 172: Default timed timedlock not implemented
>> FAILED 4 of 6
>> Failed Tests Total Fail Failed %
>> ===================================================
>> testprocmutex 6 4 66.67%
>>
>> apr-1.6 (r1790305):
>> % ./testall -v testprocmutex
>> testprocmutex : -flock_timedlock() not implemented,-Line 194: Locks don't appear to work with timedlock
>> -fcntl_timedlock() not implemented,FAILED 1 of 6
>> Failed Tests Total Fail Failed %
>> ===================================================
>> testprocmutex 6 1 16.67%
>>
>> we seem to be going backwards (apr-trunk includes the fallback)
>> since now we lost default_timed_timedlock()
> I tried to not modify the other (non PROC_PTHREAD) mechanisms normally.
> Could it be, e.g., r1790303 (which is not in 1.6.x either)?
>
> Anyway, I just commited another fallback (r1790436), could you please
> test this version on OSX?
> If pshared mutex+cond still do not work as expected on OSX, maybe we
> could un-configure it (i.e. ac_have_pthread_condattr_setpshared="no")
> and let it fall through the new generic fallback...
This is on OSX 10.11.6 with clang from XCode 8.2.1.
trunk:
$ ./testall -v testprocmutex
testprocmutex : SUCCESS
/Error 61 occurred attempting to reach memcached on localhost:11211. Skipping apr_memcache tests...
/Error 61 occurred attempting to reach Redis on localhost:6379. Skipping apr_redis tests...
All tests passed.
1.6.x:
$ ./testall -v testprocmutex
testprocmutex : -flock_timedlock() not implemented,-Line 194: Locks don't appear to work with timedlock
-fcntl_timedlock() not implemented,FAILED 1 of 6
Failed Tests Total Fail Failed %
===================================================
testprocmutex 6 1 16.67%
FWIW both trunk and branch have a new warning on OSX in maintaner mode:
.../atomic/unix/builtins.c:71:53: warning: passing 'const void *' to parameter of type 'volatile void *' discards
qualifiers [-Wincompatible-pointer-types-discards-qualifiers]
return (void*) __sync_val_compare_and_swap(mem, cmp, with);
^~~
-- Brane
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c
test/testlock.c
Posted by Jim Jagielski <ji...@jaguNET.com>.
As of HEAD on apr-trunk, all tests pass fine on OSX.
Plus:
./include/arch/unix/apr_private.h:#define HAVE_PTHREAD_CONDATTR_SETPSHARED 1
So I'm +1 for backporting to 1.6!
> On Apr 6, 2017, at 2:49 PM, Yann Ylavic <yl...@gmail.com> wrote:
>
> On Thu, Apr 6, 2017 at 1:40 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>> apr-trunk (r1790379):
>> % ./testall -v testprocmutex
>> testprocmutex : -Line 189: Locks don't appear to work with timedlock
>> -flock_timedlock() not implemented,/Line 189: Locks don't appear to work with timedlock
>> -Line 189: Locks don't appear to work with timedlock
>> -fcntl_timedlock() not implemented,-Line 133: create the mutex
>> /default_timed_timedlock() not implemented,-Line 172: Default timed timedlock not implemented
>> FAILED 4 of 6
>> Failed Tests Total Fail Failed %
>> ===================================================
>> testprocmutex 6 4 66.67%
>>
>> apr-1.6 (r1790305):
>> % ./testall -v testprocmutex
>> testprocmutex : -flock_timedlock() not implemented,-Line 194: Locks don't appear to work with timedlock
>> -fcntl_timedlock() not implemented,FAILED 1 of 6
>> Failed Tests Total Fail Failed %
>> ===================================================
>> testprocmutex 6 1 16.67%
>>
>> we seem to be going backwards (apr-trunk includes the fallback)
>> since now we lost default_timed_timedlock()
>
> I tried to not modify the other (non PROC_PTHREAD) mechanisms normally.
> Could it be, e.g., r1790303 (which is not in 1.6.x either)?
>
> Anyway, I just commited another fallback (r1790436), could you please
> test this version on OSX?
> If pshared mutex+cond still do not work as expected on OSX, maybe we
> could un-configure it (i.e. ac_have_pthread_condattr_setpshared="no")
> and let it fall through the new generic fallback...
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c test/testlock.c
Posted by Yann Ylavic <yl...@gmail.com>.
On Thu, Apr 6, 2017 at 1:40 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> apr-trunk (r1790379):
> % ./testall -v testprocmutex
> testprocmutex : -Line 189: Locks don't appear to work with timedlock
> -flock_timedlock() not implemented,/Line 189: Locks don't appear to work with timedlock
> -Line 189: Locks don't appear to work with timedlock
> -fcntl_timedlock() not implemented,-Line 133: create the mutex
> /default_timed_timedlock() not implemented,-Line 172: Default timed timedlock not implemented
> FAILED 4 of 6
> Failed Tests Total Fail Failed %
> ===================================================
> testprocmutex 6 4 66.67%
>
> apr-1.6 (r1790305):
> % ./testall -v testprocmutex
> testprocmutex : -flock_timedlock() not implemented,-Line 194: Locks don't appear to work with timedlock
> -fcntl_timedlock() not implemented,FAILED 1 of 6
> Failed Tests Total Fail Failed %
> ===================================================
> testprocmutex 6 1 16.67%
>
> we seem to be going backwards (apr-trunk includes the fallback)
> since now we lost default_timed_timedlock()
I tried to not modify the other (non PROC_PTHREAD) mechanisms normally.
Could it be, e.g., r1790303 (which is not in 1.6.x either)?
Anyway, I just commited another fallback (r1790436), could you please
test this version on OSX?
If pshared mutex+cond still do not work as expected on OSX, maybe we
could un-configure it (i.e. ac_have_pthread_condattr_setpshared="no")
and let it fall through the new generic fallback...
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c
test/testlock.c
Posted by Jim Jagielski <ji...@jaguNET.com>.
apr-trunk (r1790379):
% ./testall -v testprocmutex
testprocmutex : -Line 189: Locks don't appear to work with timedlock
-flock_timedlock() not implemented,/Line 189: Locks don't appear to work with timedlock
-Line 189: Locks don't appear to work with timedlock
-fcntl_timedlock() not implemented,-Line 133: create the mutex
/default_timed_timedlock() not implemented,-Line 172: Default timed timedlock not implemented
FAILED 4 of 6
Failed Tests Total Fail Failed %
===================================================
testprocmutex 6 4 66.67%
apr-1.6 (r1790305):
% ./testall -v testprocmutex
testprocmutex : -flock_timedlock() not implemented,-Line 194: Locks don't appear to work with timedlock
-fcntl_timedlock() not implemented,FAILED 1 of 6
Failed Tests Total Fail Failed %
===================================================
testprocmutex 6 1 16.67%
we seem to be going backwards (apr-trunk includes the fallback)
since now we lost default_timed_timedlock()
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c test/testlock.c
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Apr 5, 2017 at 1:35 PM, Branko Čibej <br...@apache.org> wrote:
> On 05.04.2017 12:52, Branko Čibej wrote:
>> On 05.04.2017 12:50, Yann Ylavic wrote:
>>> On Wed, Apr 5, 2017 at 12:42 PM, Branko Čibej <br...@apache.org> wrote:
>>>> On 05.04.2017 12:39, Yann Ylavic wrote:
>>>>> On Wed, Apr 5, 2017 at 12:27 PM, Branko Čibej <br...@apache.org> wrote:
>>>>>> On 05.04.2017 12:19, Yann Ylavic wrote:
>>>>>>> On Tue, Apr 4, 2017 at 10:57 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>>>>>>>>> On Apr 4, 2017, at 4:29 PM, Yann Ylavic <yl...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm not a big fan of the "sleep" fallback implementation.
>>>>>>>>>
>>>>>>>> Feel free to replace it with something better.
>>>>>>> Would an implementation based on a pipe (hence two FDs per mutex) be acceptable?
>>>>>> The default open-file limit on the Mac is a paltry 256, I'm not sure
>>>>>> it'd be a good idea for APR to suddenly start using up file descriptors
>>>>>> for timed waits on mutexes.
>>>>> Yes, that was my fear...
>>>>>
>>>>>> Couldn't we use a condition variable for this?
>>>>> We can for thread-mutexes (was the case before this commit), but not
>>>>> for proc-mutexes since OSX also lacks pshared condvars (i.e.
>>>>> PTHREAD_CONDATTR_SETPSHARED).
>>>> Not according to the header files. The declaration is there, available
>>>> since OSX 10.4 and iOS 2.0, which I'd say means it's pretty much
>>>> available always.
>>> Ah great, so we can probably do something for these versions and
>>> return ENOTIMPL for earliers.
>>> I won't be able to test anything on Mac(s), may I commit or propose
>>> something blindly and one test it?
>> Go ahead and propose blindly and I'll test it.
>
> Actually ... you have to own the mutex in order to call
> pthread_cond_(timed)wait. That sort of defeats the purpose of this
> exercise ...
FWIW (on OSX), r1790330 for a fallback with a condvar...
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c
test/testlock.c
Posted by Branko Čibej <br...@apache.org>.
On 05.04.2017 12:52, Branko \u010cibej wrote:
> On 05.04.2017 12:50, Yann Ylavic wrote:
>> On Wed, Apr 5, 2017 at 12:42 PM, Branko \u010cibej <br...@apache.org> wrote:
>>> On 05.04.2017 12:39, Yann Ylavic wrote:
>>>> On Wed, Apr 5, 2017 at 12:27 PM, Branko \u010cibej <br...@apache.org> wrote:
>>>>> On 05.04.2017 12:19, Yann Ylavic wrote:
>>>>>> On Tue, Apr 4, 2017 at 10:57 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>>>>>>>> On Apr 4, 2017, at 4:29 PM, Yann Ylavic <yl...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm not a big fan of the "sleep" fallback implementation.
>>>>>>>>
>>>>>>> Feel free to replace it with something better.
>>>>>> Would an implementation based on a pipe (hence two FDs per mutex) be acceptable?
>>>>> The default open-file limit on the Mac is a paltry 256, I'm not sure
>>>>> it'd be a good idea for APR to suddenly start using up file descriptors
>>>>> for timed waits on mutexes.
>>>> Yes, that was my fear...
>>>>
>>>>> Couldn't we use a condition variable for this?
>>>> We can for thread-mutexes (was the case before this commit), but not
>>>> for proc-mutexes since OSX also lacks pshared condvars (i.e.
>>>> PTHREAD_CONDATTR_SETPSHARED).
>>> Not according to the header files. The declaration is there, available
>>> since OSX 10.4 and iOS 2.0, which I'd say means it's pretty much
>>> available always.
>> Ah great, so we can probably do something for these versions and
>> return ENOTIMPL for earliers.
>> I won't be able to test anything on Mac(s), may I commit or propose
>> something blindly and one test it?
> Go ahead and propose blindly and I'll test it.
Actually ... you have to own the mutex in order to call
pthread_cond_(timed)wait. That sort of defeats the purpose of this
exercise ...
-- Brane
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c
test/testlock.c
Posted by Branko Čibej <br...@apache.org>.
On 05.04.2017 12:50, Yann Ylavic wrote:
> On Wed, Apr 5, 2017 at 12:42 PM, Branko \u010cibej <br...@apache.org> wrote:
>> On 05.04.2017 12:39, Yann Ylavic wrote:
>>> On Wed, Apr 5, 2017 at 12:27 PM, Branko \u010cibej <br...@apache.org> wrote:
>>>> On 05.04.2017 12:19, Yann Ylavic wrote:
>>>>> On Tue, Apr 4, 2017 at 10:57 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>>>>>>> On Apr 4, 2017, at 4:29 PM, Yann Ylavic <yl...@gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> I'm not a big fan of the "sleep" fallback implementation.
>>>>>>>
>>>>>> Feel free to replace it with something better.
>>>>> Would an implementation based on a pipe (hence two FDs per mutex) be acceptable?
>>>> The default open-file limit on the Mac is a paltry 256, I'm not sure
>>>> it'd be a good idea for APR to suddenly start using up file descriptors
>>>> for timed waits on mutexes.
>>> Yes, that was my fear...
>>>
>>>> Couldn't we use a condition variable for this?
>>> We can for thread-mutexes (was the case before this commit), but not
>>> for proc-mutexes since OSX also lacks pshared condvars (i.e.
>>> PTHREAD_CONDATTR_SETPSHARED).
>> Not according to the header files. The declaration is there, available
>> since OSX 10.4 and iOS 2.0, which I'd say means it's pretty much
>> available always.
> Ah great, so we can probably do something for these versions and
> return ENOTIMPL for earliers.
> I won't be able to test anything on Mac(s), may I commit or propose
> something blindly and one test it?
Go ahead and propose blindly and I'll test it.
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c test/testlock.c
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Apr 5, 2017 at 12:42 PM, Branko Čibej <br...@apache.org> wrote:
> On 05.04.2017 12:39, Yann Ylavic wrote:
>> On Wed, Apr 5, 2017 at 12:27 PM, Branko Čibej <br...@apache.org> wrote:
>>> On 05.04.2017 12:19, Yann Ylavic wrote:
>>>> On Tue, Apr 4, 2017 at 10:57 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>>>>>> On Apr 4, 2017, at 4:29 PM, Yann Ylavic <yl...@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>> I'm not a big fan of the "sleep" fallback implementation.
>>>>>>
>>>>> Feel free to replace it with something better.
>>>> Would an implementation based on a pipe (hence two FDs per mutex) be acceptable?
>>> The default open-file limit on the Mac is a paltry 256, I'm not sure
>>> it'd be a good idea for APR to suddenly start using up file descriptors
>>> for timed waits on mutexes.
>> Yes, that was my fear...
>>
>>> Couldn't we use a condition variable for this?
>> We can for thread-mutexes (was the case before this commit), but not
>> for proc-mutexes since OSX also lacks pshared condvars (i.e.
>> PTHREAD_CONDATTR_SETPSHARED).
>
> Not according to the header files. The declaration is there, available
> since OSX 10.4 and iOS 2.0, which I'd say means it's pretty much
> available always.
Ah great, so we can probably do something for these versions and
return ENOTIMPL for earliers.
I won't be able to test anything on Mac(s), may I commit or propose
something blindly and one test it?
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c
test/testlock.c
Posted by Branko Čibej <br...@apache.org>.
On 05.04.2017 12:39, Yann Ylavic wrote:
> On Wed, Apr 5, 2017 at 12:27 PM, Branko \u010cibej <br...@apache.org> wrote:
>> On 05.04.2017 12:19, Yann Ylavic wrote:
>>> On Tue, Apr 4, 2017 at 10:57 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>>>>> On Apr 4, 2017, at 4:29 PM, Yann Ylavic <yl...@gmail.com> wrote:
>>>>>
>>>>>
>>>>> I'm not a big fan of the "sleep" fallback implementation.
>>>>>
>>>> Feel free to replace it with something better.
>>> Would an implementation based on a pipe (hence two FDs per mutex) be acceptable?
>> The default open-file limit on the Mac is a paltry 256, I'm not sure
>> it'd be a good idea for APR to suddenly start using up file descriptors
>> for timed waits on mutexes.
> Yes, that was my fear...
>
>> Couldn't we use a condition variable for this?
> We can for thread-mutexes (was the case before this commit), but not
> for proc-mutexes since OSX also lacks pshared condvars (i.e.
> PTHREAD_CONDATTR_SETPSHARED).
Not according to the header files. The declaration is there, available
since OSX 10.4 and iOS 2.0, which I'd say means it's pretty much
available always.
-- Brane
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c
test/testlock.c
Posted by Jim Jagielski <ji...@jaguNET.com>.
We *could* consider using macOS native for everything...
Ugg.
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c
test/testlock.c
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Apr 5, 2017, at 2:22 PM, Yann Ylavic <yl...@gmail.com> wrote:
>
>
> My reasoning is rather that we implement a generic pshared condvar
> solution (like we do for thread-mutexes), and if it does not work on
> OSX (because for some reasons their condvar does not work as
> advertised or in any sane manner), well, let them responsible for
> their bugs.
Can this generic pshared condvar be used no matter WHAT serialize
an OS has? The point is that anything under "unix" is assumed to
be pthread, not posix-sem and not sysv-sem because, if that was
NOT the case, this would have been more an issue earlier, since
other unix-like systems would have been affected. So saying
we have a work-around for pthread_mutex_trylock() and only
pthread_mutex_trylock() isn't enough. If we have a *better*
impl for pthread_mutex_trylock() that what is in there now,
great, but we can't short change those platforms that
use posix-sem or sysv-sem or, even worse, those that
specifically BUILD their systems to USE these semaphore/lock
mechanisms.
As such, we have no idea how well this works posix-sem or
sysv-sem... we assume OK, but from what I can tell no
one has ever tickled that codepath because everyone gets/uses
pthreads.
The assumption that "it's been in trunk" should be enough
to warrant inclusion isn't quite valid... once we start
considering *releasing* the code, then we need to look
at the new stuff and consider if it is really ready for
prime time. Instead, we have something that was sitting
for a year, but never used, and thus never exercised, and
what limited testing there was, just tested/exercised a single
impl out of 3 for our main platform, "unix".
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c test/testlock.c
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Apr 5, 2017 at 3:27 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Wed, Apr 5, 2017 at 8:22 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>> As noted in a previous thread regarding the values of timeouts
>> related to the 3 major timedwait() canon implementations, I'm not
>> exactly sure how well thought out and tested these are.
There is (was hopefuly, since possibly fixed in r1790296) indeed an
overlook on *1* of 7 (beos, netware, os2, the 3 unixes mechanisms
where applicable, and windows) on the passed in relative vs absolute
timeout, I wouldn't call that a badly thought or untested feature
(admittedly the existing unit tests, because they *do* exist, did not
caught it...).
Now, let's say the words, we encounter a buggy system (w.r.t.
timedlock only of course), for which we can't propose a fix (closed
sources) and in the name of which we'd mark apr_*_mutex_timedlock()
experimental.
My reasoning is rather that we implement a generic pshared condvar
solution (like we do for thread-mutexes), and if it does not work on
OSX (because for some reasons their condvar does not work as
advertised or in any sane manner), well, let them responsible for
their bugs.
I've just implemented this condvar fallback, it seems to work on linux
(where I forcibly #undef
HAVE_PTHREAD_MUTEX_TIMEDLOCK), and will propose it on the related thread.
Frankly, I don't understand why it's more experimental than any other
thing introduced in 1.6.x, it's been in trunk for a while (and in
1.6.x for another while) for everyone to review it.
While working on this, I also fixed several bugfixes our (non
timedwait) implementation, mainly in error pathes IIRC, that didn't
prevent the APR to release ortable mutexes until now.
But after all, I don't want to be the defender of a lost cause, so
let's say it's experimental...
>> Putting
>> them in 1.6 means that people will start using them, and we could
>> discover brokenness after the fact, and end-users will need to
>> work around that brokenness while waiting on the next APR patch
>> release...
>
> Linux is sysv by default. Windows are native (using native API).
The rationale of APR_LOCK_DEFAULT_TIMED is that one must use it at
mutex creation time to be able to use timedlock later.
So for e.g. thread mutexes on Windows, it means that we create a Mutex
instead of the default CRITICAL_SECTION, so that we can
WaitForSingleObject() (not do-able otherwise).
The same applies to unixes,
apr_proc_mutex_create(APR_LOCK_DEFAULT_TIMED) should pick up the best
implementation (usually PROC_PTHREAD when they are robust, even if
APR_USE_SYSVSEM_SERIALIZE is configured and/or other syscalls like
semtimedop() or sem_timedwait() are also available).
If none is available but pthread_condattr_setpshared() is (like in
OSX, if it works..), we can fall back to it.
Otherwise, I see no other choice than spinning sleep or ENOTIMPL(-ementable).
Does it sound experimental?
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c test/testlock.c
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Apr 5, 2017 at 8:22 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> As noted in a previous thread regarding the values of timeouts
> related to the 3 major timedwait() canon implementations, I'm not
> exactly sure how well thought out and tested these are. Putting
> them in 1.6 means that people will start using them, and we could
> discover brokenness after the fact, and end-users will need to
> work around that brokenness while waiting on the next APR patch
> release...
Linux is sysv by default. Windows are native (using native API).
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c
test/testlock.c
Posted by Jim Jagielski <ji...@jaguNET.com>.
As noted in a previous thread regarding the values of timeouts
related to the 3 major timedwait() canon implementations, I'm not
exactly sure how well thought out and tested these are. Putting
them in 1.6 means that people will start using them, and we could
discover brokenness after the fact, and end-users will need to
work around that brokenness while waiting on the next APR patch
release...
My only concern is that I'm not sure if these are ready for
Prime Time and if putting them in 1.6 will bite us, and any end-users
who use them, in the butt.
Are ANY platforms using the SysV and/or Posix versions?
> On Apr 5, 2017, at 9:11 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> On Wed, Apr 5, 2017 at 6:46 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>>
>>> On Apr 5, 2017, at 6:39 AM, Yann Ylavic <yl...@gmail.com> wrote:
>>>
>>>
>>> Agreed, there seems to be few (if any) alternatives, though, but:
>>> avoid using apr_proc/global_mutex_timedlock() on OSX is recommended.
>>> Should we make it explicit with ENOTIMPL?
>>>
>>
>> Maybe we should reconsider the whole idea of timedlocks??
>
> Without throwing them out wholesale, in the interest of other 1.6.0
> enhancements, is it reasonable to keep developing this on 2.0-dev
> trunk, and back it out entirely from 1.6.x branch for now? (Not sure
> if forking 1.7.x from 1.6.x and then backing out from 1.6.x is the
> simplest way to make that happen, but guessing it is.)
>
> If the recent activity is indicative of a renewed interest in APR, either
> 2.0.0 or 1.7.0 aught to follow sometime reasonable, certainly by this
> time in '18, or perhaps this fall in conjunction with ACEU?
>
> I'd personally like to stay with niq's goal of a prompt release and
> see this widely adopted long before ACUS, so we can start to dive
> into what 2.0/1.7 will look like.
>
>
>> And besides, isn't the project called Apache *Portable* Runtime?
>> Back when we started it this project, the idea was that if
>> Platform Foo lacked a function we "needed", APR would provide
>> it, not simply willy-nilly say "Nah, ENOTIMPL!". Sure, maybe
>> it wasn't the "best" implementation, but we tried. That
>> whole idea was to have each system/platform have some level
>> of *parity*. Have we reversed that?
>
> There are things that can't be implemented, but we do our best
> to keep the developer above that fray. E.g. the developer does
> need to be aware that Win32 doesn't fork(). But it's a decision
> tree such as 'APR_HAS_FORK'? Not 'am I coding for Windows?'
>
> Agree that if we can implement a functionality for a missing
> platform, we aught to.
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c
test/testlock.c
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Apr 5, 2017, at 1:28 PM, Nick Kew <ni...@apache.org> wrote:
>
> On Wed, 5 Apr 2017 10:53:30 -0500
> William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
>>>> Howbout a --with-experimental-timedlocks config option ?
>>>
>>> +1
>>>
>>> although anyone toggling an -experimental flag is expected
>>> to understand their resulting apr breaks binary compatibility.
>>
>> Or... do we stub them in all as APR_ENOTIMPL if the experimental
>> flag is not given?
>
> Sounds like a plan.
>
> Keep API/ABI compatible either way, get the new code some exposure,
> but only among users who ticked the disclaimer!
>
/me like
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c
test/testlock.c
Posted by Nick Kew <ni...@apache.org>.
On Wed, 5 Apr 2017 10:53:30 -0500
William A Rowe Jr <wr...@rowe-clan.net> wrote:
> >> Howbout a --with-experimental-timedlocks config option ?
> >
> > +1
> >
> > although anyone toggling an -experimental flag is expected
> > to understand their resulting apr breaks binary compatibility.
>
> Or... do we stub them in all as APR_ENOTIMPL if the experimental
> flag is not given?
Sounds like a plan.
Keep API/ABI compatible either way, get the new code some exposure,
but only among users who ticked the disclaimer!
--
Nick Kew
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c test/testlock.c
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Apr 5, 2017 at 9:17 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Wed, Apr 5, 2017 at 8:57 AM, Nick Kew <ni...@apache.org> wrote:
>> On Wed, 2017-04-05 at 08:11 -0500, William A Rowe Jr wrote:
>>
>>> > Maybe we should reconsider the whole idea of timedlocks??
>>>
>>> Without throwing them out wholesale, in the interest of other 1.6.0
>>> enhancements, is it reasonable to keep developing this on 2.0-dev
>>> trunk, and back it out entirely from 1.6.x branch for now?
>>
>> Howbout a --with-experimental-timedlocks config option ?
>
> +1
>
> although anyone toggling an -experimental flag is expected
> to understand their resulting apr breaks binary compatibility.
Or... do we stub them in all as APR_ENOTIMPL if the experimental
flag is not given?
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c test/testlock.c
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Apr 5, 2017 at 8:57 AM, Nick Kew <ni...@apache.org> wrote:
> On Wed, 2017-04-05 at 08:11 -0500, William A Rowe Jr wrote:
>
>> > Maybe we should reconsider the whole idea of timedlocks??
>>
>> Without throwing them out wholesale, in the interest of other 1.6.0
>> enhancements, is it reasonable to keep developing this on 2.0-dev
>> trunk, and back it out entirely from 1.6.x branch for now?
>
> Howbout a --with-experimental-timedlocks config option ?
+1
>> (Not sure
>> if forking 1.7.x from 1.6.x and then backing out from 1.6.x is the
>> simplest way to make that happen, but guessing it is.)
>
> Please, no 1.7 until 1.6-release is out of the door!
>
> We can then decide whether a 1.7 is needed, or whether the
> future can be 2.0 and bugfixes.
It shouldn't be hard to copy 1.6.x at any pre-backout tag to 1.7.x,
and then forward port the short list of commits.
But the suggestion above renders this issue moot. I like it,
although anyone toggling an -experimental flag is expected
to understand their resulting apr breaks binary compatibility.
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c
test/testlock.c
Posted by Nick Kew <ni...@apache.org>.
On Wed, 2017-04-05 at 08:11 -0500, William A Rowe Jr wrote:
> > Maybe we should reconsider the whole idea of timedlocks??
>
> Without throwing them out wholesale, in the interest of other 1.6.0
> enhancements, is it reasonable to keep developing this on 2.0-dev
> trunk, and back it out entirely from 1.6.x branch for now?
Howbout a --with-experimental-timedlocks config option ?
> (Not sure
> if forking 1.7.x from 1.6.x and then backing out from 1.6.x is the
> simplest way to make that happen, but guessing it is.)
Please, no 1.7 until 1.6-release is out of the door!
We can then decide whether a 1.7 is needed, or whether the
future can be 2.0 and bugfixes.
--
Nick Kew
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c test/testlock.c
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Apr 5, 2017 at 6:46 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>
>> On Apr 5, 2017, at 6:39 AM, Yann Ylavic <yl...@gmail.com> wrote:
>>
>>
>> Agreed, there seems to be few (if any) alternatives, though, but:
>> avoid using apr_proc/global_mutex_timedlock() on OSX is recommended.
>> Should we make it explicit with ENOTIMPL?
>>
>
> Maybe we should reconsider the whole idea of timedlocks??
Without throwing them out wholesale, in the interest of other 1.6.0
enhancements, is it reasonable to keep developing this on 2.0-dev
trunk, and back it out entirely from 1.6.x branch for now? (Not sure
if forking 1.7.x from 1.6.x and then backing out from 1.6.x is the
simplest way to make that happen, but guessing it is.)
If the recent activity is indicative of a renewed interest in APR, either
2.0.0 or 1.7.0 aught to follow sometime reasonable, certainly by this
time in '18, or perhaps this fall in conjunction with ACEU?
I'd personally like to stay with niq's goal of a prompt release and
see this widely adopted long before ACUS, so we can start to dive
into what 2.0/1.7 will look like.
> And besides, isn't the project called Apache *Portable* Runtime?
> Back when we started it this project, the idea was that if
> Platform Foo lacked a function we "needed", APR would provide
> it, not simply willy-nilly say "Nah, ENOTIMPL!". Sure, maybe
> it wasn't the "best" implementation, but we tried. That
> whole idea was to have each system/platform have some level
> of *parity*. Have we reversed that?
There are things that can't be implemented, but we do our best
to keep the developer above that fray. E.g. the developer does
need to be aware that Win32 doesn't fork(). But it's a decision
tree such as 'APR_HAS_FORK'? Not 'am I coding for Windows?'
Agree that if we can implement a functionality for a missing
platform, we aught to.
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c
test/testlock.c
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Apr 5, 2017, at 6:39 AM, Yann Ylavic <yl...@gmail.com> wrote:
>
>
> Agreed, there seems to be few (if any) alternatives, though, but:
> avoid using apr_proc/global_mutex_timedlock() on OSX is recommended.
> Should we make it explicit with ENOTIMPL?
>
Maybe we should reconsider the whole idea of timedlocks??
And besides, isn't the project called Apache *Portable* Runtime?
Back when we started it this project, the idea was that if
Platform Foo lacked a function we "needed", APR would provide
it, not simply willy-nilly say "Nah, ENOTIMPL!". Sure, maybe
it wasn't the "best" implementation, but we tried. That
whole idea was to have each system/platform have some level
of *parity*. Have we reversed that?
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c test/testlock.c
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Apr 5, 2017 at 12:27 PM, Branko Čibej <br...@apache.org> wrote:
> On 05.04.2017 12:19, Yann Ylavic wrote:
>> On Tue, Apr 4, 2017 at 10:57 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>>>> On Apr 4, 2017, at 4:29 PM, Yann Ylavic <yl...@gmail.com> wrote:
>>>>
>>>>
>>>> I'm not a big fan of the "sleep" fallback implementation.
>>>>
>>> Feel free to replace it with something better.
>> Would an implementation based on a pipe (hence two FDs per mutex) be acceptable?
>
> The default open-file limit on the Mac is a paltry 256, I'm not sure
> it'd be a good idea for APR to suddenly start using up file descriptors
> for timed waits on mutexes.
Yes, that was my fear...
>
> Couldn't we use a condition variable for this?
We can for thread-mutexes (was the case before this commit), but not
for proc-mutexes since OSX also lacks pshared condvars (i.e.
PTHREAD_CONDATTR_SETPSHARED).
> Spinning in sleep() is
> less than efficient.
Agreed, there seems to be few (if any) alternatives, though, but:
avoid using apr_proc/global_mutex_timedlock() on OSX is recommended.
Should we make it explicit with ENOTIMPL?
Regards,
Yann.
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c
test/testlock.c
Posted by Branko Čibej <br...@apache.org>.
On 05.04.2017 12:19, Yann Ylavic wrote:
> On Tue, Apr 4, 2017 at 10:57 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>>> On Apr 4, 2017, at 4:29 PM, Yann Ylavic <yl...@gmail.com> wrote:
>>>
>>>
>>> I'm not a big fan of the "sleep" fallback implementation.
>>>
>> Feel free to replace it with something better.
> Would an implementation based on a pipe (hence two FDs per mutex) be acceptable?
The default open-file limit on the Mac is a paltry 256, I'm not sure
it'd be a good idea for APR to suddenly start using up file descriptors
for timed waits on mutexes.
Couldn't we use a condition variable for this? Spinning in sleep() is
less than efficient.
-- Brane
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c test/testlock.c
Posted by Yann Ylavic <yl...@gmail.com>.
On Tue, Apr 4, 2017 at 10:57 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>
>> On Apr 4, 2017, at 4:29 PM, Yann Ylavic <yl...@gmail.com> wrote:
>>
>>
>> I'm not a big fan of the "sleep" fallback implementation.
>>
>
> Feel free to replace it with something better.
Would an implementation based on a pipe (hence two FDs per mutex) be acceptable?
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x:
locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c
test/testlock.c
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Apr 4, 2017, at 4:29 PM, Yann Ylavic <yl...@gmail.com> wrote:
>
>
> I'm not a big fan of the "sleep" fallback implementation.
>
Feel free to replace it with something better.