Damnit, I didn't reply-to-all .. ;-)
On Mon, May 07, 2001, Robert Collins wrote:
> refcounted io buffers for the filter code.
Aahaha. How'd I guess? :-)
> refcount differs from cbdata in that it's being passed along a chain of
> users that _may split_. And if the chain splits, then two cbdataFree's
> would occur.
Yup, I've noted this.
> 1) a source (say http server side code) creates a buffer bar. (locks=1)
> 2) bar then gets passed to the broker. the broker doesn't lock the
> buffer - it doesn't care about it. However the broker passes the buffer
> to _both_ the object store for storage and the client side code for
> passing to the client.
> 3) both the store and the client lock the buffer until they've
> respectively commited and sent it. (locks=3)
> 4) the source unlocks the buffer once the call chain returns. (locks=2)
> 5) the store completes (locks=1)
> 6) the client side write completes (locks=0, buffer is freed).
Right.
> I'm happy to use straight cbdata, with an overlaid unLock and Lock
> function and put in a _new_ refcount variable - but that seems rather..
> uhmm wasteful. I'd far rather reuse the cbdata locks variable.
The cbdata system was never designed as a refcounted allocator - it
was designed as a verifyer of callback pointers. What we probably
want to do is extend the cbdata allocator to take a "free on refcount -> 0"
flag when we setup a cbdata pool.
Unless you can think of a clean place to call cbdataFree() :-)
Adrian
Received on Mon May 07 2001 - 06:55:27 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:00 MST