On Tue, Apr 4, 2017 at 3:09 PM, <j...@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.
