On Mon, 29 Jun 2009, Mohun Biswas wrote:
- The doc states that curl_multi_perform "will only execute as little as
possible and then return back control to your program". Taken literally this
would mean it transfers one byte with each "ready" socket, but I'm guessing
it really means that one buffer's worth is exchanged, and return
CURLM_CALL_MULTI_PERFORM if more could be done?
For an application usign the socket API it's not less work to get one byte
compared to many. So it might read a whole lot of bytes per multi_perform()
invoke. Or just a single byte.
- The docs also say "It is designed to never block". A common idiom
mentioned in the docs and used often in the examples is to call
curl_multi_perform in a loop:
while (CURLM_CALL_MULTI_PERFORM == curl_multi_perform(...));
if I understand correctly, this will will treat all easy handles "fairly"
without blocking, but will effectively "block" any non-curl-related activity
until all curl transfers are done. Is that right?
Sure, but that while() is in the app not in libcurl.
In other words I think I shouldn't use the above loop if my program has
other high-priority things to do?
Perhaps. That's your call.
- Is there a technique for "serializing" the multi API? By which I mean
something like a flag to change the "as little as possible" philosophy to
"as much as possible", which would make it behave much more synchronously
like the easy API.
I don't understand what such a "serializing" would mean so I can't really tell
how hard it would be.
--
/ daniel.haxx.se
