On Mon, May 22, 2017 at 3:22 PM, Yann Ylavic <ylavic....@gmail.com> wrote: > On Mon, May 22, 2017 at 4:56 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: >> On May 19, 2017 2:21 PM, "William A Rowe Jr" <wr...@rowe-clan.net> wrote: >> >> [+0.9] Release current svn _timedlock API implementation in 1.6 > > I won't complain if it's not released, but I'm not sure there are still > issues. > IIUC (from latest Rainer's tests), the remaining failure on Solaris > was with apr_thread_mutex_timedlock(), which I changed in r1794266 to > have a similar implementation to apr_thread_mutex_timedlock() (which > seems to work as expected now). > I did not backported r1794266 to 2.4.x because I was waiting for > feedbacks (did I miss some new results?). > > Likewise, I tried to address the Windows "int64 usecs to uint32 msecs > truncation" issue in r1792620. > > From an API perspective, the single timeout argument looks consensual. > So there may still be some bug(s) somewhere, which we would fix as > always, but it would unlikely break existing applications since it's > new feature, hence my positive vote...
Hi Yann, I trust that 1.7.x branch with your contribution has addressed most early concerns. I still needed to read back through the various debates to determine that most everyone's concerns are addressed. I was hoping to see more unconditional +1's in support of this addition at the present moment, considering how many contributors have made small corrections and more significant enhancements, but it seems that our community is still 'iffy' on whether this is ready for broad distribution. I *hope* that many of us, once 1.6.1 is out the door, will spend time to not only verify (and document in doxygen) our platforms' behavior, but find some great application cases for this code. Very important to add the functionality to not lock indefinitely, and not simply rely on spotty platform-by-platform deadlock avoidance logic. > PS: really sorry for the delay and the lack of activity these days, I > had so few spare times... Understood and no worries, this was what ultimately kept my vote at +/-0 although I was nearly up to a +.5 - but that would have meant still further delays in gathering consensus, enhancing the test framework, addressing any lingering problems, etc. It seemed unfair to continue to block on 1.6.x GA while we prepare this new API. So... my biggest hopes are for a successful 1.6.1 GA and planning for a late summer/early autumn 1.7.0 / 2.0.0 GA that introduces this new feature. Thanks for all of your hard work and looking forward to helping make this happen. Cheers, Bill
