Curl passes c-ares sockets to the CURLMOPT_SOCKETFUNCTION but does not open them via the CURLOPT_OPENSOCKETFUNCTION

[marc-groundctl]

I did this

I am using the curl multi interface with boost::asio, which cannot wait on sockets without taking ownership of them. For most sockets this is fine, since curl will create them via the CURLOPT_OPENSOCKETFUNCTION callback and close them with the CURLOPT_CLOSESOCKETFUNCTION callback, so asio can open and close them on its own. However, c-ares does not use those functions and instead opens and closes the sockets itself. This means that when curl passes the c-ares socket to the CURLMOPT_SOCKETFUNCTION it isn't owned by asio, and asio can't take ownership of the socket because c-ares will later close the socket. This means the program can't wait on data from that socket and so can't call curl_multi_socket_action at the right time.

I expected the following

Curl should use the OPEN/CLOSESOCKETFUNCTION to open/close c-ares sockets.

curl/libcurl version

curl 7.61.0-DEV (x86_64-pc-linux-gnu) libcurl/7.61.0-DEV OpenSSL/1.1.0h zlib/1.2.11 brotli/1.0.5 c-ares/1.14.0 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.4) nghttp2/1.32.0
Release-Date: [unreleased]
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile NTLM NTLM_WB SSL libz brotli TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL

operating system

Linux, Windows

[bagder]

This became possible in c-ares 1.13.0 and I think that would be a good thing to support.

[bagder]

Thanks, but this description sounds as if you're asking for a new feature/change. We use this tracker for bugs and issues only, we put ideas to work on in the future in the TODO document. We basically drown in good ideas so they don't do much use in our tracker.

If you really want to see this happen, start working on an implementation and submit a PR for it or join the mailing list and talk up more interest for it and see what help from others you can get!