Re: curl_multi_socket_action, http pipelining
Date: Mon, 18 Aug 2008 14:24:32 +0200
On Aug 18, 2008, at 2:47 AM, George Kola wrote:
> >> I)First question is about step 3. Documentation (http://
> >> curl.haxx.se/libcurl/c/curl_multi_socket.html) says there should be
> >> no reason to use curl_multi_socket_all. If I am not to use it, what
> >> should I use in step 3 (curl_multi_perform ?)
> >You don't need to call curl_multi_socket_all, anytime you think you
> >need to call it must be considered a bug somewhere. Adding the easy
> ?handle should generate a socket and/or timeout callback, so you can
> >add the socket to your event backend. When the socket becomes
> >readable or writable, you call curl_multi_socket_action on it. You
> >don't manually have to "start" the transfer. At least I never did.
> I find that when I add an easy handle to multi handle, only
> the timeout callback (set with CURLMOPT_TIMERFUNCTION) is called
> with a timeout of 0 and the socket callback is not called. Is this
> normal ?
Yes. A timeout of "0 means that the timeout is already reached", so
that you should call curl_multi_socket_action with
CURL_SOCKET_TIMEOUT some time before you would block in the event
loop. Normally you would just insert a timer set to "now" in the
event loop and have that take care of it automatically. It is
probably better to not call curl_multi_socket_action directly from
the callback, or you could get recursion problems (I do not know if
curl_multi_socket_action is supposed to support recursion, but it's
better to assume that it does not). Wait until the previous
curl_multi_socket_action call returned at least for this reason.
> I now have my code set a flag if timeout_ms==0 and after
> adding an handle to multi handle, I check this flag and call
> curl_multi_socket_action with CURL_SOCKET_TIMEOUT. Is this the
> correct way ?
Since you need to support timers anyway, why not just insert a
regular timer with 0 ms and then have that event call libcurl? The
event backend, whichever you're using, should have no problem with
that. You don't really gain anything by handling a zero timeout
> I find that after the first call with CURL_SOCKET_TIMEOUT,
> the timeout_ms passes is 299,999 -- this seems a long time (almost
> 5 minutes). Am I doing something wrong ?
That's normal. It's the inactivity timeout; if by that time no
sockets have become readable or have errors, that just lets libcurl
clean up. Normally you would get socket events much before that, and
libcurl would then adjust the timeout as needed.
> I also find that on every further addition of an easy
> handle, the CURLMOPT_TIMERFUNCTION gets called with a timeout of 0.
> So, should I keep calling call curl_multi_socket_action with
> CURL_SOCKET_TIMEOUT on every addition of an easy handle to a multi
Just once after adding all handles is fine, which is how it would
work if you just add a 0 ms timer to your event backend.
Simply do this regardless of what value libcurl tells you, add the
timer and your event backend will take care of the rest. (Unless the
value is -1, then you should either do nothing or remove the timer.)
Basically, a timeout of 0 means "when you're done with this and have
nothing better to do than block in the event loop, call
curl_multi_socket_action with CURL_SOCKET_TIMEOUT."
I think this is also a simple test initially whether your timers
work, because if it gets stuck right in the beginning, they didn't
work. So don't try to short-circuit this, there's really no benefit
-- Josef Drexler josef_at_ttdpatch.netReceived on 2008-08-18