On Thu, 14 Feb 2019, Chris Dolfin wrote:

>> For these long-going HTTP streams, curl_easy_perform() will not return
>> until the connection closes and that might take a long time until it does.
>
> Is my application going to block on curl_easy_perform() in this case?

Yes, that's how curl_easy_perform() works. If you want non-blocking,
curl_multi_perform() is your friend.

>> And for most situaitons, I would imagine that you'd just loop then and do
>> another request again to allow for more "events" to arrive.
>
> This is what I an unable to understand. Which library call do I loop around?
> curl_easy_perform() ?

I would presume so, yes.

> Which request do I send again?

Now we're getting into the subtle details on how these events are meant to
actually work and be used on HTTP level, and I'm not quite sure. I would
imagine that you'd send more or less the same request again.

>> While curl_easy_perform() sits waiting for more events nothing happens but
>> as soon as data arrives it will call the write callback and your
>> application can deal with it.
>
> How do I get notified that the write callback has finished assembling the
> message and I can read the full message?

Uh? The function called by the write callback is *your code*. You know when it
gets called, you know what it does and you should be able to know when it has
gotten a full message. curl cannot. curl doesn't know anything about the data
it delivers or the format of it.

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