After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 659255 - SoupHTTPInputStream: use a list of SoupBuffers instead of a buffer for leftover data
SoupHTTPInputStream: use a list of SoupBuffers instead of a buffer for leftov...
Status: RESOLVED FIXED
Product: libsoup
Classification: Core
Component: Misc
unspecified
Other Linux
: Normal normal
: ---
Assigned To: libsoup-maint@gnome.bugs
libsoup-maint@gnome.bugs
Depends on:
Blocks:
 
 
Reported: 2011-09-16 14:54 UTC by Sergio Villar
Modified: 2011-11-07 18:15 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch (5.29 KB, patch)
2011-09-16 14:58 UTC, Sergio Villar
reviewed Details | Review
Patch using subbuffers (5.47 KB, patch)
2011-10-13 15:14 UTC, Sergio Villar
accepted-commit_now Details | Review

Description Sergio Villar 2011-09-16 14:54:33 UTC
SoupHTTPInputStream currently uses its own buffer to store received data that is pending to be read. Instead we can just store a list of buffers pending to be read. That would save us several realloc() and memcpy() if the client does not read from the stream quickly enough.
Comment 1 Sergio Villar 2011-09-16 14:58:29 UTC
Created attachment 196735 [details] [review]
Patch
Comment 2 Dan Winship 2011-10-11 17:12:01 UTC
Comment on attachment 196735 [details] [review]
Patch

sorry it took me so long to get back to this...

basically good, but you can simplify a bit and get rid of one more memcpy:

>+	g_queue_push_head (priv->leftover_queue, soup_buffer_copy (chunk_buffer));
>+	priv->leftover_offset = chunk_buffer->length - chunk_size;

instead of soup_buffer_copy(chunk_buffer), do:

    soup_buffer_new_subbuffer(chunk_buffer, chunk_buffer->length - chunk_size, chunk_size);

so you're only "copying" the part of the buffer you haven't used yet. And then you don't need priv->leftover_offset at all.

And then in read_from_leftover(), you can remove priv->leftover_offset, and in the else case, instead of memcpy()ing data around in the existing SoupBuffer, just make another new subbuffer, and replace the queue head with that.
Comment 3 Sergio Villar 2011-10-11 17:21:47 UTC
(In reply to comment #2)
> (From update of attachment 196735 [details] [review])
> sorry it took me so long to get back to this...
> 
> basically good, but you can simplify a bit and get rid of one more memcpy:

Cool, didn't know about the subbuffer stuff. Will provide a new patch.
Comment 4 Sergio Villar 2011-10-12 10:25:25 UTC
(In reply to comment #2)
> (From update of attachment 196735 [details] [review])
> sorry it took me so long to get back to this...
> 
> basically good, but you can simplify a bit and get rid of one more memcpy:

[...]

> And then in read_from_leftover(), you can remove priv->leftover_offset, and in
> the else case, instead of memcpy()ing data around in the existing SoupBuffer,
> just make another new subbuffer, and replace the queue head with that.

I understand what you mean except the reference to getting rid of a memcpy. Even if we do what you propose we still have at the end to copy the contents from the soup buffer to the users' buffer (which is not a SoupBuffer).
Comment 5 Dan Winship 2011-10-12 12:56:30 UTC
oops, I misread the code; I thought it was moving data around inside the SoupBuffer at the end. So yeah, you won't actually get rid of a memcpy().
Comment 6 Sergio Villar 2011-10-13 09:32:08 UTC
Maybe we can change the API later and force the caller to pass a SoupBuffer instead of a generic pointer.
Comment 7 Dan Winship 2011-10-13 13:46:01 UTC
sure. I still think it's worth using the subbuffers anyway though. it will at least get rid of leftover_offset
Comment 8 Sergio Villar 2011-10-13 15:14:35 UTC
Created attachment 198944 [details] [review]
Patch using subbuffers
Comment 9 Sergio Villar 2011-11-07 18:15:19 UTC
This was committed some time ago 399c6105b7eda992d521cb55c96ededbbb456187