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 <j...@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?
