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 ... -- Brane