Hi Dimitry, > Am 22.02.2025 um 17:50 schrieb Dimitry Andric via curl-library > <curl-library@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.html
