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
