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: Dimitry Andric via curl-library <curl-library_at_lists.haxx.se>
Date: Sun, 23 Feb 2025 14:01:21 +0100
On 23 Feb 2025, at 09:51, Stefan Eissing <stefan_at_eissing.org> wrote:
>
>> 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.)
Thanks for your explanation. This is all perfectly fine, and at least I
now know that it is by design.
I had wanted to put in a pull request to add documentation about it, but
re-reading https://curl.se/libcurl/c/curl_multi_cleanup.html I saw that
it is already mentioned:
> When this function is called, remaining entries in the connection
> pool held by the multi handle are shut down, which might trigger calls
> to the CURLMOPT_SOCKETFUNCTION callback.
So I should probably have read the documentation more carefully. :)
-Dimitry
Date: Sun, 23 Feb 2025 14:01:21 +0100
On 23 Feb 2025, at 09:51, Stefan Eissing <stefan_at_eissing.org> wrote:
>
>> 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.)
Thanks for your explanation. This is all perfectly fine, and at least I
now know that it is by design.
I had wanted to put in a pull request to add documentation about it, but
re-reading https://curl.se/libcurl/c/curl_multi_cleanup.html I saw that
it is already mentioned:
> When this function is called, remaining entries in the connection
> pool held by the multi handle are shut down, which might trigger calls
> to the CURLMOPT_SOCKETFUNCTION callback.
So I should probably have read the documentation more carefully. :)
-Dimitry
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2025-02-23