Re: CLOSESOCKETFUNCTION not always called in multi

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