On Wed, 7 Apr 2004, Gisle Vanem wrote:

> > Right, but when it switches to CURLM_STATE_CONNECT it is because it wants
> > to connect to a server. It might then first resolve the host name
> > asynchronously, and when that happens it switches over to
> > CURLM_STATE_WAITRESOLVE and if it resolves the name synchronously it
> > switches to CURLM_STATE_WAITCONNECT.
>
> Okay, I think I got that part. But why then does multi.c in
> CURLM_STATE_WAITCONNECT state need to concern itself with sockets since
> there are none (except a c-ares socket).

Because the app shouldn't be forced to call curl_multi_perform() non-stop. It
can instead just wait for something to happen on one of the sockets that
libcurl manages.

> I fail to see why multi-clients should need to use select() at all. This
> should IMHO be hidden away in curl_multi_perform() etc.

Then you've missed one of the major design goals with the multi interface. By
allowing the app to do the select(), the app can not only decide itself when
to do it, it can also wait on its own file descriptors/sockets in the same
single select().

> Especially in resolve state. Wouldn't a multi-client reading from those
> sockets confuse c-ares trying to read from the same sockets?

The multi-client only select()s on the socket(s), it never fiddles with (reads
from or writes to) any of libcurl's sockets. If one of them shows activity,
curl_multi_perform() is called and that should deal with the sockets properly.

-- 
     Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
      Dedicated custom curl help for hire: http://haxx.se/curl.html