Re: buffer management [was Re: libsoup-2.4 branch merged to trunk]

[Wouter Cloetens <wouter mind be>]

On Mon, Feb 04, 2008 at 09:38:57PM -0500, Dan Winship wrote:
> Wouter Cloetens wrote:
> > Patch attached to bug 513810.
> 
> I saw that. I didn't love it. It really violates the abstraction of
> SoupBuffer.

True. Additionally, my first patch caused a double free, and my second
patch caused a memory leak, so it's also wrong.

> > I discovered a third issue; GStreamer allows for downstream elements to
> > allocate the buffers in which to write. This is especially useful if the
> > next element in the pipeline does hardware buffer management to offload
> > some operation to hardware.
> > To manage that, I'd need to be able to configure a callback to do the
> > actual allocation. That should be easy enough... Tomorrow's job.
> 
> That seems a lot nicer; we could make a new SoupBuffer subtype
> representing data owned by another object, with a GDestroyNotify
> attached to clean things up, and then the allocation callback would
> allocate SoupBuffers, and everything should just work...
> 
> What do you think of the attached diff? I think this would let you solve
> both of your issues (hardware buffer management, and the original
> I-want-smaller-buffers-and-no-copies thing).

I actually want bigger buffers, but smaller is conceivable too. ;-)
I like the idea of the allocator being able to pause the flow, and I'm
happy to see the distinction between data and destroy_data.
It's not clear to me if the destroynotify feature can let me interact
with GStreamer's GstBuffer correctly, but I'll try to work with this
tonight when I have more time to look into it.

bfn & thx,
Wouter