On Tue, 25 Feb 2003, Avery Fay wrote:

> 64 is not a magic number. It has something to do with how I calling
> curl_multi_info_read (and subsequent calls to curl_multi_remove_handle and
> curl_multi_add_handle). I rewrote this section of code and it seems to work
> now.

Ah, goodie! Let me know if there's anything we should add to a man page or
anything that would make things clearer.

> Is there a foolproof way to know when I should call curl_multi_info_read?
> Right now, I check running_handles that curl_multi_perform returns. For
> example, if I start up 64 connections and running_handles comes back as 63,
> I figure something has happened and I should call curl_multi_info_read to
> find out. Is this a valid assumption?

Yes, that's how I've visualized this being used. There's not a very big
penalty if you call curl_multi_info_read() too often, but if the running
handles number hasn't changed, you won't have any new 'messages' to read.

> I also have a couple of questions about curl_multi_info_read. It looks like
> it can return a number of different things.

At least that's the intention.

> I've had it return NULL, CURLMSG_DONE, CURLMSG_LAST, and maybe CURLMSG_NONE
> (not sure about that one). In what circumstances will it return these?

It returns NULL when there's no new message to return.

It returns a pointer to a struct where 'info->msg' contains CURLMSG_DONE when
a single easy-handle has moved over to the 'completed' state.
'info->easy_handle' is then the CURL handle and the 'info->data.result'
contains the 'CURLcode' of that particular transfer.

Presently, there is no other things this can return. If it does, then it is a
bug.

> Especially, when will it return NULL and CURLMSG_NONE? If there is at least
> one CURLMSG_DONE will there also be one CURLMSG_LAST?

Can you provide an example that makes it return anything other than
CURLMSG_DONE?

> BTW, libcurl with the multi interface scales nicely. Now that I've gotten
> it somewhat working, I'm running 4 processes each with 1000 simultaneous
> connections for a total of 4000 simultaneous connections.

That certainly is good news!

-- 
 Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs.
-------------------------------------------------------
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp