cURL / Mailing Lists / curl-library / Single Mail


Re: question about curl_multi_perform, callbacks, and presenting a pull interface

From: Rich Bramante <>
Date: Thu, 23 Aug 2012 18:50:47 -0400

On Thu, Aug 23, 2012 at 6:15 PM, Daniel Stenberg <> wrote:
> On Thu, 23 Aug 2012, Rich Bramante wrote:
> Right, but libcurl will not "read everything that comes until there's
> nothing more to read" so it should be a finite number of bytes.
> I would say the biggest problem is if you use automatic decompression of
> data as then it can probably become a significant amount if a very easy
> compressible data stream is sent.
> --
> /

Thanks Daniel.

So even if there is data on the socket curl will not invoke the write
callback "forever" without returning control back to the application?
I do not mind buffering a handful of CURL_MAX_WRITE_SIZE buffers but
would not want to buffer many.

So in that scheme this would be safe:

1) library calls curl_multi_perform
2) 0, 1 or N write callbacks will be invoked but N is "semi-limited"
regardless of how much data is available. Buffer the write callback
data into 1 or more internal library buffers.
3) Return to caller after curl_multi_perform returns. Caller Read()'s
which my library satisfies from its internally buffered data. It does
not call curl_multi_perform again while it has data buffered and hence
no write callbacks should be invoked. When there is no data buffered
internally, go to step 1 and repeat until curl returns no more data.

Does this sound like the best/most reasonable approach?

List admin:
Received on 2012-08-24