> On Mar 4, 2015, at 2:43 PM, Graham Leggett <[email protected]> wrote: > > On 04 Mar 2015, at 8:59 PM, Jim Jagielski <[email protected]> wrote: > >> I am wondering if we are continuing to use RINGs in places >> where we should really migrate to using skiplists. afaict, we >> used RINGs initially because it was the only valid and available >> data structure we could use, but it was not idea. Even >> now, we aren't really using it as a FIFO queue and whenever >> we access it, we appear to be trying to do so in a sorted >> way (as related to time stamps)... I may end up doing >> some tests to see what the performance diffs would be if >> we instead just used skiplists. > > In my digging into how to get the request output filters to support > asynchronous behaviour, what I needed was a list of filters that had setaside > data, and that in turn needed to be kicked with empty brigades to keep > writing until they were empty. I take it a skiplist would be a better idea > for this than an APR_RING? > > Another place where it has become apparent that a list is required is the > chain of input and output filters. Right now, they’re just linked together > with next pointers, and a really ugly hack to insert or remove the first > filter into the conn_rec or request_rec. Ideally these should be a linked > list like an APR_RING (or a skiplist?), so they can be cleanly referenced and > modified without messing about. >
I was thinking mostly about the way the Event MPM uses RINGs, but yeah, I can see places where skiplists could "take over" other areas. Since filters have a sort order, they seem like candidates for skiplists.
