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: Socket callbacks during curl_multi_cleanup()
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Stefan Eissing via curl-library <curl-library_at_lists.haxx.se>
Date: Sun, 23 Feb 2025 09:51:07 +0100
Hi Dimitry,
> Am 22.02.2025 um 17:50 schrieb Dimitry Andric via curl-library <curl-library_at_lists.haxx.se>:
>
> You can see that handle_socket() is now being called _during_ the
> curl_multi_cleanup() call, whereas that did not happen before.
>
> As far as we can determine, these callbacks occur because a58b50fca
> introduces an extra internal handle in conncache.c, which gets triggered
> with a CURL_POLL_IN event, followed by a CURL_POLL_REMOVE.
>
> The question is whether that was intentional or not?
This has, unfortunately, come as a surprise to other libcurl applications as well.
The reason why this happens is that libcurl is shutting down all connections
in its cache at `curl_multi_cleanup()` in a "best effort" way. For connections
involving SSL, this will send the "close notify" message to the remote server.
For HTTP/2 connections, this also sends the GOAWAY frame.
If the application has registered a socket callback, this may involve invoking
that callback. As you notice. If this is important to an application or not,
depends on how the application uses this information.
Let's say the application uses libuv. If the application calls `uv_stop(loop)`
right after `curl_multi_cleanup()` then the accounting of socket event via the
socket callback does not matter. The `uv_stop()` will throw that all away.
If the application wants to keep on using the uv loop, it is necessary to forward
callback invocation to the loop during `curl_multi_cleanup()` or uv will continue
monitoring sockets that have been gone. (This may lead to immediate failures, if
the socket number is then BAD or it may not as many operating system reassign
a just closed socket number to the next opened one.)
Hope this helps,
Stefan
>
> -Dimitry
>
> --
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
Date: Sun, 23 Feb 2025 09:51:07 +0100
Hi Dimitry,
> Am 22.02.2025 um 17:50 schrieb Dimitry Andric via curl-library <curl-library_at_lists.haxx.se>:
>
> You can see that handle_socket() is now being called _during_ the
> curl_multi_cleanup() call, whereas that did not happen before.
>
> As far as we can determine, these callbacks occur because a58b50fca
> introduces an extra internal handle in conncache.c, which gets triggered
> with a CURL_POLL_IN event, followed by a CURL_POLL_REMOVE.
>
> The question is whether that was intentional or not?
This has, unfortunately, come as a surprise to other libcurl applications as well.
The reason why this happens is that libcurl is shutting down all connections
in its cache at `curl_multi_cleanup()` in a "best effort" way. For connections
involving SSL, this will send the "close notify" message to the remote server.
For HTTP/2 connections, this also sends the GOAWAY frame.
If the application has registered a socket callback, this may involve invoking
that callback. As you notice. If this is important to an application or not,
depends on how the application uses this information.
Let's say the application uses libuv. If the application calls `uv_stop(loop)`
right after `curl_multi_cleanup()` then the accounting of socket event via the
socket callback does not matter. The `uv_stop()` will throw that all away.
If the application wants to keep on using the uv loop, it is necessary to forward
callback invocation to the loop during `curl_multi_cleanup()` or uv will continue
monitoring sockets that have been gone. (This may lead to immediate failures, if
the socket number is then BAD or it may not as many operating system reassign
a just closed socket number to the next opened one.)
Hope this helps,
Stefan
>
> -Dimitry
>
> --
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2025-02-23