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. 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?

I also have a couple of questions about curl_multi_info_read. It looks
like it can return a number of different things. 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? Especially, when will it
return NULL and CURLMSG_NONE? If there is at least one CURLMSG_DONE will
there also be one CURLMSG_LAST?

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.

 
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/25/2003 03:32 AM
Please respond to curl-library

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

On Mon, 24 Feb 2003, Avery Fay wrote:

> I'm currently migrating my app to the curl multi interface and I'm
having a
> problem. Basically, I add 64 easy handles to the multi handle. Call
perform
> and the app hangs. From gdb output it looks like gettimeofday is not
> returning. Also, netstat shows 64 open connections with data in the
receive
> queue. Does this ring a bell with anyone?

Not to me. Is the number 64 a magic limit that makes this problem appear?

I can't understand why gettimeofday() would be a problem.

(And to be honest, I've never tried this amount of connections myself but
I
can't see any reason why a larger amount would cause problems.)

> 1.) Is the multi interface thread safe? Can I have multiple threads each
> with their own multi handle?

Yes. The multi interface is as thread-safe as the rest of libcurl.

> 2.) After I call curl_multi_fdset, do I ever need to call it again? Does
> curl continue to use the same fdsets that I gave it?

You should basicly call curl_multi_fdset() whenever you're about to do
select(). Each easy-handle can (and will) change file handles in between
calls.

> 3.) If a function returns the error code that means I have to call
> curl_multi_perform again is it imperative that I call that before doing
> another select?

Well, it's highly recommended, not mandatory. If you select() before
calling
it again, even though it returned CURLM_CALL_MULTI_PERFORM, libcurl may
still
have data locally that it should send off to the peer or to a local
callback.

-- 
 Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf