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