On Mon, 6 Feb 2006, Sun Yi Ming wrote:

> When a easy handle is new added, it's state is CURLM_STATE_INIT, it dosn't
> wait anything; when it goes to CURLM_STATE_DONE, it wait nothing and can go
> CURLM_STATE_COMPLETED, am i wrong? Either we need perform one easy handle
> until it do wait some events or goto end, or we should have a way to run
> these handles periodically.

Right, but this makes curl_multi_perform() return CURLM_CALL_MULTI_PERFORM,
right? That is a hint to the app to call *perform() again without waiting for
socket action.

I do however think that we should remove the CURLM_CALL_MULTI_PERFORM return
code one day and make curl_multi_perform() perform as much as possible instead
and only return when it would otherwise have to block waiting on a socket.
It is what the apps want anyway and it'll make nicer apps.

>> When select() returns non-zero, you know that Y out of Z connections had
>> socket action. How can libcurl tell which the Y connections are without
>> going over all the Z ones?
>
> In fact, i don't understand this, but i guess the curl_multi_socket do the
> proper thing.

Yes it does. I thought you were suggesting some kind of in-between approach...

> If you mean how libcurl can report events, in the body
> curl_multi_perform_nonblock there may have attempt to do io things so events
> are reported, the other handles' events are kept not changed.

I meant that I don't understand what your patch and suggestion does and what
goodness it brings!

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html