On Tue, 18 Feb 2025, Malcolm Matalka via curl-library wrote:

After this thread I talked to Daniel and your analysis is exactly correct. These are other sockets that the multi interface is working with, not sockets associated with an handle. One solution is to "--disable-socketpair", as you said, which rather than use those sockets ends up switching to a polling mechanism for those sockets.

Let me elaborate a little.

The threaded resolver uses a file desrciptor for communicating when it has completed. This is what --disable-socketpair disables. Without the communication, curl will instead poll regularly. It uses a little more CPU and it might increase latency a bit.

That file descriptor is not sent to the CLOSESOCKETFUNCTION because it is not created by the open counterpart. It is often not even a socket (depending on build conditions and platform). This build option removes that file descriptor from the equation.

Say you instead build the c-ares resolver backend, then you might get several additional file descriptors that are used for and by the name resolver mechanism. Sockets that are created and own by c-ares and we only get to know about them from that library and we neither create nor close them directly ourselves - only indirectly with c-ares function calls. (Building without c-ares avoids those file descriptors.)

This way we have a number of different file descriptors that need to be monitored and when they have activity need action. It can also not be ruled out that additional ones might be introduced in a future for other or similar purposes.

For example: we work on adding HTTPS-RR support, which adds c-ares file descriptors to the mix *together* with the socketpair sockets when using the threaded resolver.

Introducing a concept that blocks the closing of certain file descriptors after curl has finished using them is a rather big complication.

--

 / daniel.haxx.se || https://rock-solid.curl.dev
--
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Reply via email to