On Mon, Jun 29, 2009 at 10:46, Daniel Stenberg<daniel_at_haxx.se> 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
>
Received on 2009-07-01