On Wed, 12 Sep 2018, Nicolás Bagnasco wrote:
Sadly I am the maintainer of an old app which is not mine, and some parts of
the networking code that handles http connections uses the same code from
the asiohiper example.
It reminds us of the importance to make sure the examples are correct and
working as they should. It is tricky, because we also want to have a low bar
in accepting new examples as examples are a very good way to show people how
the library can be used...
In that situation libcurl should've already told your app that it wants to
wait on that socket to become writable and when it does (when it can send the
request over it), you should've called libcurl telling it about that fact. Did
that happen or not?
I'm not sure about what you are trying to tell me here but I assume
that you are referring to CURLMOPT_SOCKETFUNCTION.
If that's the case, I think I need to understand what's going on with
the CURL_POLL_IN and CURL_POLL_OUT events because it seems that it's
handled in the example, I don't know however if it's handled the way
it should.
Yes.
The CURLMOPT_SOCKETFUNCTION is informed by libcurl that "hey, please wait for
WRITABILITY (CURL_POLL_OUT) on socket X" after the connection has been
established, and once boost::asio then notices that the socket is ready for
"writing", your application should call curl_multi_socket_action() telling
libcurl about this event.
That's pretty much the gist of how the event-based API works. libcurl tells
the app what to wait for (and a timeout). The app then tells libcurl about the
event when it happens.
When you say libcurl never sends the request of the connection, we need to
figure out what activities (CURL_POLL_IN / CURL_POLL_OUT) curl asked you to
wait for and what activities on that socket you told libcurl to act on with
curl_multi_socket_action().
--
/ daniel.haxx.se
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
