Re: CURLM Chain of events
Date: Thu, 21 Jan 2016 23:41:22 +0100 (CET)
On Thu, 21 Jan 2016, surf via curl-library wrote:
> I'm a bit confused about the semantics and dealing with the various CURLM
> events. Here is a high-level description of my setup (Windows). I embedded
> my questions within.
Let me try to explain. But also, I'm not at all familar with event-based
programming on Windows so while I can tell you the libcurl side I don't know
the Windows implementation details.
This said, are you even intending to use libcurl event-based?
The event based API is curl_multi_socket_action() and friends. Event-based
(just in case it isn't clear) means you use some sort of system that monitors
all sockets in use right now and as soon as there's an "event" on one of them,
you call the necessary function that acts on that socket.
The "normal" multi API is not event based and uses the curl_multi_perform()
function to drive the transfers. It is design to have you extract the file
descriptors from libcurl, call select() and then call curl_multi_perform() as
soon as there's activity (or timeout).
So this is the regular multi interface. Then I understand the confusion.
This makes me hesitate if I should go on and answer the rest of the questions
because they're all related to the multi_socket API that you don't seem to be
using. But maybe its just a mistake? OK, I'll try to answer them anyway.
Just keep the two different approaches in your mind when proceeding from here.
> // Here curl is telling me via CURL_POLL_IN/OUT that it wants me to tell it
> // when the socket is ready for read/write.
The socket callback is for the multi_socket API. You can ignore it otherwise.
The timer callback is also for the multi_socket API. With the ordinary multi
API you typically either use curl_multi_wait() *or* you extract the file
descriptors and timeout value with curl_multi_fdset() and
> // Here curl tells me to give up waiting for socket readiness after Xms
> Q1: How does it figure X ?
> Q2: When I start my program I noticed curl raises this event 3 times before
> raising any other events.. Why is that?
It figures out X based on what it does and what needs it has for the moment,
based on what states the current running transfers are in.
It may call the callback several times when it needs to uptime the timeout
value (even if it isn't really meant to do it many times, I think you may see
this because you're not using curl_multi_socket_action()).
> "When the curl_multi_socket_action function runs, it informs the application
> about updates in the socket (file descriptor) status by doing none, one, or
> multiple calls to the socket_callback"
This is again describing the multi_socket functionality.
> What exactly am I supposed to do in socket_callback for this case ?
The socket_callback is your code. libcurl calls it to inform about what
sockets you should monitor for its sake. It adds, removes or changes the
sockets you monitor.
When there's activity on one of those sockets, you call libcurl and tell it
That's basically how event-based socket handling works.
> Since I'm only supposed to pass CURL_SOCKET_TIMEOUT and not sockfd,
You're supposed to pass CURL_SOCKET_TIMEOUT on timeouts and you're supposed to
pass a socket descriptor when there's socket activity.
-- / daniel.haxx.se
List admin: http://cool.haxx.se/list/listinfo/curl-library
Received on 2016-01-21