I will provide a patch for the stack implementation of reslit: to be posted on the bug referenced in my first mail. For the second part, i simply suggest to implement a maximum lifetime feature alike an acquire timeout feature was added in revision 58964 of apr_reslist.c: +> add a new API call say "apr_reslist_maxlifetime_set" alike the apr_reslist_timeout_set(xx) +> change reslist_acquire functions to implement this maxlifetime feature if set So if one wants to use a lifetime feature, he will simply have to call apr_reslist_timeout_set(xx). Otherwise, default behaviour will remain.
----- Message d'origine ---- De : Aaron Bannert <[EMAIL PROTECTED]> À : Christian BOITEL <[EMAIL PROTECTED]> Cc : [email protected] Envoyé le : Mercredi, 6 Septembre 2006, 7h30mn 56s Objet : Re: reslist API does not provide proper size regulation On Thu, Aug 31, 2006 at 07:06:10AM +0000, Christian BOITEL wrote: > Following my discussion on this topic with rpluem on bugzilla, i am posting > this one to submit you a change in the reslit pool management to ensure > proper pool size regulation and some API changes to better handle this part > of the list management. > > See my initial toughts on > http://issues.apache.org/bugzilla/show_bug.cgi?id=40348 The failure of the reslist to shrink back down after load subsides does sound like a valid bug to me. If you could provide a patch that changes the maint routine to search from the end of the list, and also a change to make the list behave like a stack instead of a queue, that would be great. As for changing the meaning of TTL, I'm not so sure that's needed after the above changes. If you need to invalidate a resource, you can use the apr_reslist_invalidate() routine. To implement a strict maximum lifetime for your resources, simply check your own timer after aquiring a new resource, and call the invalidate routine if it's too old, and then try to get another resource. -aaron
