On Fri, 27 Sep 2002, Fabrizio Ammollo wrote:

> OK. So, any time I call curl_multi_perform, if I want to be sure that all
> the available data has been transferred, I have to loop until
> CURLM_CALL_MULTI_PERFORM is returned

If you want to be sure, you call it again if CURLM_CALL_MULTI_PERFORM is
returned, yes.

> or I can decide to arbitrarily call curl_multi_perform less times and call
> it later. This is the most elastic way, I think, leaving the decision to
> the application.

Right, you call curl_multi_perform() when you think it is fit. But I don't
recommend doing select() as long as the previous curl_multi_perform()
function returned CURLM_CALL_MULTI_PERFORM, as then you might be left
"hanging" for network input when there already is things to do.

> Today I have written a little test program which, within the infinite loop,
> the first n iterations it calls select() with a timeout of 1/100s, and upon
> each timeout a new easy handle is created, added to the multi handle and
> curl_multi_perform is called until something different from
> CURLM_CALL_MULTI_PERFORM is returned. After all the planned connections
> have started, I use a blocking select to save CPU cycles :-) and then I
> loop again calling curl_multi_perform only when data is available.
>
> I've seen that, even with n = 60, the while loop after the creation of the
> easy handle executes at most three times, and the same kind of loop,
> executed when data is available, executes at most one time. This is VERY
> GOOD, because it guarantees me that the application will never block more
> than necessary (except for DNS resolution maybe, but I know that a solution
> to this is in being worked). And this, transferring in parallel bytes
> ranging from 1Kb up to 1.2Mb ! It works very well !!

Right, the DNS resolving is the by far biggest "blocking" code right now.
There are a few other things as well, but they're not very big and so they
hardly never get noticed.

> After calling curl_multi_perform I have a check, made only after at least
> one easy handle has been started and if the previous number of running
> connections is greater than the current one, that repeatedly calls
> curl_multi_info_read and for each CURLMSG_DONE the correspondent easy
> handle is looked up into my connections array in order to clean it up. It
> works. :-)

Neato. That's how it is intended to work! ;-)

> I have one doubt: after the end of an easy transfer, its state into the
> multi handle it set to something like "COMPLETED", right ?

Correct.

> So, if nothing sets its state to "INIT", how is it possible to reuse the
> same easy handle to immediately perform another transfer within the same
> multi handle ?

> There's another way to set again its state to "INIT" other than removing
> and readding the easy handle to the multi handle ? Which is not
> complicated, but it seems avoidable to me...

Currently: you remove the easy handle from the multi handle (set any possibly
new options) and add it again. Voila. Just as you say.

I discussed a shortcut for this with someone (was it Giuseppe Attardi?), that
would allow you to call curl_multi_add_handle() on a easy handle that has
completed - without removing it first - and that would then set it to INIT
and restart another transfer. This is currently not supported though, but if
anyone is keen on this I'll appreciate a patch!

-- 
 Daniel Stenberg -- curl related mails on curl related mailing lists please
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf