Backporting reslist changes?

[Rainer Jung <ra...@kippdata.de>]

I dont't remember the outcome of the discussions, but are any of the 
following three reslist changes reasonable for 1.6 backport?

------------------------------------------------------------------------
r1834030 | ylavic | 2018-06-21 19:06:34 +0200 (Thu, 21 Jun 2018) | 6 lines

apr_reslist: always expire oldest entries first.

When a resource is to be acquired, we should check for expiring entries
starting from the oldest to the youngest one, otherwise it's only when
the latter expires that all of the resources are killed in a batch.

------------------------------------------------------------------------
r1834061 | ylavic | 2018-06-21 23:49:40 +0200 (Thu, 21 Jun 2018) | 5 lines

apr_reslist: don't release/re-acquire the mutex in apr_reslist_release().

We can hold the mutex for the whole release time by adding and using an
unlocked reslist_maintain() helper, and ensure more fairness for the 
releaser.

------------------------------------------------------------------------
r1834064 | ylavic | 2018-06-22 00:17:48 +0200 (Fri, 22 Jun 2018) | 3 lines

apr_reslist: put common code in push_resource().

Regards,

Rainer

Re: Backporting reslist changes?

[Nick Kew <ni...@apache.org>]

> On 25 Aug 2018, at 15:03, Rainer Jung <ra...@kippdata.de> wrote:
> 
> I dont't remember the outcome of the discussions, but are any of the following three reslist changes reasonable for 1.6 backport?

IMHO No.  If it ain't broke, don't fix it in 1.6.
Changes that call for non-trivial or production testing belong in 1.7,
along with the crypto updates and possibly the json from amongst
what's been happening on trunk.

-- 
Nick Kew