cURL / Mailing Lists / curl-library / Single Mail


Re: questions about multi API

From: Hardeep Singh <>
Date: Tue, 30 Jun 2009 22:26:21 -0700

On Mon, Jun 29, 2009 at 10:46, Daniel Stenberg<> 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?


>> 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.
> --
>  /
Received on 2009-07-01