apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <ylavic....@gmail.com>
Subject 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
Date Wed, 05 Apr 2017 10:50:59 GMT
On Wed, Apr 5, 2017 at 12:42 PM, Branko ─îibej <brane@apache.org> wrote:
> On 05.04.2017 12:39, Yann Ylavic wrote:
>> On Wed, Apr 5, 2017 at 12:27 PM, Branko ─îibej <brane@apache.org> wrote:
>>> On 05.04.2017 12:19, Yann Ylavic wrote:
>>>> On Tue, Apr 4, 2017 at 10:57 PM, Jim Jagielski <jim@jagunet.com> wrote:
>>>>>> On Apr 4, 2017, at 4:29 PM, Yann Ylavic <ylavic.dev@gmail.com>
>>>>>> 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.
> 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?

View raw message