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
