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 <j...@jagunet.com> wrote: >>>>>>>>> On Apr 4, 2017, at 4:29 PM, Yann Ylavic <ylavic....@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...
