cURL / Mailing Lists / curl-library / Single Mail


Re: questions about multi API

From: Mohun Biswas <>
Date: Mon, 06 Jul 2009 10:15:26 -0400

Daniel Stenberg wrote:
> But also, the times libcurl returns CURLM_CALL_MULTI_PERFORM calling
> it again to do the next action shouldn't add up to a lot extra, so in
> the end you will hardly ever notice that while loop in your app
> anyway.
> I think that return code was perhaps a mistake to introduce, and a
> future version of libcurl might just take care of that looping
> internally instead to simplify the API somewhat.

I guess there's a fundamental thing I don't understand about the multi
API and I think it stems from an unclarity in the docs. If you can help
me understand it better, I'll try to make a patch clarifying the docs
the same way.

The docs say that curl_multi_perform will "transfer data on all current
transfers in the multi stack that are ready to transfer anything". Now,
assume a situation where the task is to upload a bunch of files. Each of
those files will always be "ready" in select() terms, so I'd think that
curl_multi_perform would start transfers on all of them. Meanwhile,
CURLM_CALL_MULTI_PERFORM is said to be returned when "there may be more
data to send off before it is satisfied".

As I interpret this, if curl_multi_perform is called in a loop

     while (CURLM_CALL_MULTI_PERFORM == curl_multi_perform(...));

the descriptors for the uploadable files will always be ready and this
loop won't finish until they're all transferred. The result is a
semi-synchronous situation, in that uploading will be asynchronous
*between* the files but any non-libcurl work will have to wait for the
transfers to finish.

The main unclarity is what it means to be "satisfied". Does it mean a
buffer has been filled, or all available data has been read from the
descriptor, or what? In what circumstances could it be satisfied while
there's still unread data in the files?

My program services input requests and then sends its output to a remote
site using libcurl. The input must be handled in close to real time
while output is less time sensitive. Thus the key point is that I don't
ever want to be blocked from handing an input request while waiting for
an output transfer to finish, and I'm having some trouble figuring out
how to achieve such a thing with the multi API. As noted, if I can find
out how this is supposed to work I'll try to make doc patches while it's
fresh in my mind.

Received on 2009-07-06