> On 13 Apr 2018, at 21:46, Yann Ylavic <ylavic....@gmail.com> wrote: > > On Fri, Apr 13, 2018 at 7:30 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: >> I'm still unclear why you believe we need APR to purge the elts when the >> user chooses to flip the fifo/lifo switch. That seems very wrong to me, the >> consumer can do so if that is what they desire. > > To be clear (with myself): > > /* What we have */ > APU_DECLARE(apr_status_t) apr_reslist_acquire(apr_reslist_t *reslist, > void **resource); > /* What we want */ > #define apr_reslist_acquire_lifo apr_reslist_acquire > APU_DECLARE(apr_status_t) apr_reslist_acquire_fifo(apr_reslist_t *reslist, > void **resource);
You have a plan to implement that with the existing structs? How does it work if an application mixes the two forms of acquire randomly, as seems likely if (for example) a reslist is shared between applications/components of differing provenances? I’d be reluctant to see a significant performance hit. I’m also thinking, with fifo the reslist might tend to grow bigger, as more elements are re-used well within the timeout and thus never be deleted to reduce the size. Isn’t that an argument for making reslist an either/or thing with policy determined once and for all when it’s created? — Nick Kew
