On 23 Feb 2025, at 09:51, Stefan Eissing <[email protected]> wrote: > >> Am 22.02.2025 um 17:50 schrieb Dimitry Andric via curl-library >> <[email protected]>: >> >> 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.html
