Re: [gnet] http api question

["David Sowa" <dsowa email com>]

Tim,

Thanks for the feedback, if you make any changes to this 
stuff I'll give it a go.

It seems to me that once you get into that callback function and
have the pointer to the data and the length you would want to
do one of two things depending on the context.  In my case I'm 
just looking to write it to disk so I really just want to use
that pointer and the tell the library I'm done with it and it
can be released.  In a different context you would probably want
to take control of the buffer and tell the library that you 
will free that pointer later when you are done with it.

Actually now that I think about it both of these cases are just
subcases of just getting ownership of the pointer.  So if you can
do that safely without leaking and without a buffer copy all
would be well.

regards

David
----- Original Message -----
From: "Tim Müller" <t i m zen co uk>
To: gnet gnetlibrary org
Subject: Re: [gnet] http api question
Date: Wed, 13 Apr 2005 09:17:06 +0100

> 
> On Wednesday 13 April 2005 01:43, David Sowa wrote:
> 
> Hi David,
> 
> > I'm looking at the GConnHttp documentation and it the description of the
> > GConnHttpEvent it says this:
> >
> > GNET_CONN_HTTP_DATA_PARTIAL: data has been read. The buffer is caller-owned
> > (ie. owned by GNet), but may be truncated to zero length using the
> > appropriate GString methods. You must not free the buffer
> >
> > Can this buffer really be manipulated as a GString?  I don't see any way to
> > get a GString pointer.
> 
> No, this buffer can't be manipulated as a GString. The first version of
> GConnHttp used a GString as buffer, but that wouldn't have worked in GLib-1.2
> (because it can handle embedded 0s only since GLib-2.0), so it was changed to
> the way it is now. Looks like I forgot to update this part of the
> documentation.
> 
> 
> > I was hoping to use the data at the callback level without doing yet
> > another buffer copy.
> 
> The designated way to get to the partial or complete data is
> gnet_conn_http_steal_buffer() now, which at the moment not only involves a
> buffer copy, but also seems to leak the original buffer.
> 
> The code could certainly be improved quite a bit. I'll have a look through it
> and fix the memory leaks and make sure gnet_conn_http_steal_buffer() does not
> involve a buffer copy in the next release.
> 
> Cheers
>   -Tim

-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm