apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: [VOTE] Release _timedlock API in 1.6.x?
Date Wed, 24 May 2017 15:58:13 GMT
On Mon, May 22, 2017 at 3:22 PM, Yann Ylavic <ylavic.dev@gmail.com> wrote:
> On Mon, May 22, 2017 at 4:56 PM, William A Rowe Jr <wrowe@rowe-clan.net> wrote:
>> On May 19, 2017 2:21 PM, "William A Rowe Jr" <wrowe@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.



View raw message