Hmm, I guess it doesn't return anything else. I got the CURLMSG_NONE and
CURLMSG_LAST from multi.h. Also, the man page for curl_multi_info_read is
very misleading. It implies that I would get something like CURLMSG_LAST
after the last real message and CURLMSG_NONE when there were not messages.
I like the idea of returning NULL for those situations better, but the man
page should be updated.

 
Avery Fay

Symantec Corporation
Office:
(781) 530-2489
eMail:
avery_fay_at_symantec.com

Daniel Stenberg <daniel_at_haxx.se>
Sent by: curl-library-admin_at_lists.sourceforge.net
02/26/2003 07:08 AM
Please respond to curl-library

 
        To: libcurl Mailing list <curl-library_at_lists.sourceforge.net>
        cc:
        Subject: Re: curl multi problem

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
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf