On 04/16/2018 12:04 PM, Yann Ylavic wrote:
> On Mon, Apr 16, 2018 at 8:45 AM, Ruediger Pluem <rpl...@apache.org> wrote:
>>
>> On 04/14/2018 02:32 AM, Yann Ylavic wrote:
>>>
>>> IOW, this simple patch would work equally for me (and could go in any 
>>> version):
>>>
>>> Index: util-misc/apr_reslist.c
>>> ===================================================================
>>> --- util-misc/apr_reslist.c    (revision 1829106)
>>> +++ util-misc/apr_reslist.c    (working copy)
>>> @@ -61,13 +61,13 @@ struct apr_reslist_t {
>>>  };
>>>
>>>  /**
>>> - * Grab a resource from the front of the resource list.
>>> + * Grab a resource from the back of the resource list.
>>>   * Assumes: that the reslist is locked.
>>>   */
>>>  static apr_res_t *pop_resource(apr_reslist_t *reslist)
>>>  {
>>>      apr_res_t *res;
>>> -    res = APR_RING_FIRST(&reslist->avail_list);
>>> +    res = APR_RING_LAST(&reslist->avail_list);
>>>      APR_RING_REMOVE(res, link);
>>>      reslist->nidle--;
>>>      return res;
>>> --
>>
>> Hm, but this would change this to become a fifo list instead of the current 
>> lifo list or do I miss something?
> 
> Yes clearly, I suggested that reslists be changed to FIFO
> unconditionnaly, because I find that LIFO and expiry don't mix well
> w.r.t. starvation..
> 
> That would be the simpler patch too (not that
> apr_reslist_acquire_fifo() is hard to implement, but I wonder who

I think there are scenarios where LIFO is useful, but the question is if these 
are frequent enough to warrant LIFO /
FIFO as an option.

> needs LIFO in the firtst place with such a structure...).

There seems to be no promise in the API documentation that this is LIFO, but of 
course switching to FIFO changes the
behavior of the structure for the better (as you assume) or for the worse (for 
people who build on the current
implementation detail that it is LIFO).
So the question is: Can we do that in 1.6.x or even in 1.7.x from our 
guarantees we give point of view?

Regards

RĂ¼diger

Reply via email to