On Mon, Jun 29, 2009 at 10:46, Daniel Stenberg<[email protected]> wrote: > 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.
For the reason that this loop is in the app, a separate thread can be launched to run this loop and doesn't block the rest of the app... Does this eliminate the need for serializing? -hardy > >> 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 >
