On Thu, Aug 23, 2012 at 6:15 PM, Daniel Stenberg <daniel_at_haxx.se> 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.
>
> --
>
> / daniel.haxx.se

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?

Rich
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-08-24