Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: CLOSESOCKETFUNCTION not always called in multi
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Tue, 18 Feb 2025 15:27:56 +0100 (CET)
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.
Date: Tue, 18 Feb 2025 15:27:56 +0100 (CET)
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.htmlReceived on 2025-02-18