On Mon, 13 Feb 2017, David Requena wrote:

> I understand actual data size is size * nmemb but why have it decomposed
> like this? IOW: what are size and nmemb meant to convey themselves?

They're specified like that only to match fwrite(). "nmemb items of data, each
size bytes long" as the fwrite man page says.

> CURLOPT_WRITEFUNCTION's documentation does explain very little about data
> buffering, just stating default max data size is 16K. I'm afraid libcurl
> might keep buffering events and only deliver them to my write callback in a
> big batch. That of course would negate the whole SSE idea.

The man page also says

   This callback function gets called by libcurl as soon as there is data
   received that needs to be saved

I think that implies the data is delivered fairly soon after getting received
and not a lot of extra buffering.

> Is there a way I could control when CURLOPT_WRITEFUNCTION is actually
> called? Being a binary thing I don't suppose received linefeed have any
> effect on this..

No, there's no direct way to affect that. You can shrink the used buffer size
(CURLOPT_BUFFERSIZE) which indirectly will make the function get called more
often, but you still won't get it get called sooner because of that.

libcurl uses non-blocking sockets and will call the write callback as soon as
it has received data into its buffer. It doesn't know nor care about linefeeds
or text vs binary. Everything is the same to libcurl: data.

libcurl will actually "hold" the data as short as possible before passing it
on to the application.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html