On Tue, 7 Jun 2011, Jimish Shah wrote:

(Please don't use the mailing list in digest mode when you want to reply to
mails!)

> Curl_multi_perfom() --> multi_runsingle () for every easy handle. Now
> singipconnect() is invoked with 0 timeout, connect() returns -1 and errno
> set to EINPROGRESS (maybe for a slow web server)

...

> So sockfd is set to the actual socket and we return. I cant figure out who
> keeps track of this socket if it returns here.

The multi_runsingle() function has a state machine that takes care of what to
do in various states, and while in CURLM_STATE_WAITCONNECT it will call
Curl_is_connected() to figure out when this particular socket has connected
for real.

> /lib/multi.c --> Curl_multi_perform()

Let me again state that you don't use curl_multi_perform() if you want to do
high performance handling of large amounts of connections. You then use the
multi_socket API and thus instead curl_multi_socket_action().

> As soon as Curl_multi_perform is done with this loop, we call fd_set which
> expects all the fd's to be connected.

No it doesn't. select() is called to tell when sockets are readable or
writable, it doesn't assume that the sockets are connected.

> So in simple terms, if the socket returns immediately, who keeps track and
> who triggers when the socket is connected.

The socket is stored in the connectdata struct. There's a Curl_one_easy struct
for each easy handle added to the multi handle and it identifies the correct
connectdata struct.

The rest is the state machine. Basically.

> Is it mandatory to use libevent to handle the same ?

No, as you can easily just test to verify. Using an event-based system is
however the recommended way to scale upwards and beyond several hundred
simultaneous connections.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html