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: Questions about new multi-handle notifications
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 10 Nov 2025 19:33:55 +0000
> With the notifications, you are told when there is a message to read.
I think even without CURLMNOTIFY_INFO_READ notification, the application is told when to read messages - when curl_multi_perform() returns.
It can accumulate more than one message if some transfers are completed almost simultaneously, but it should return as soon as there are messages for the client to process.
When I am reading what Stefan wrote before:
". An application using CURLMNOTIFY_INFO_READ no longer needs to explicitly call curl_multi_info_read() in its run loop.
While curl_multi_info_read() is not that expensive to call, especially event based libcurl applications had to invoke it *a lot* when processing many transfers. Especially when these transfers use many connections, and therefore sockets. The savings scale with the number of socket poll events the application processes.
While curl_multi_info_read() is not that expensive to call, especially event based libcurl applications had to invoke it *a lot* when processing many transfers. Especially when these transfers use many connections, and therefore sockets. The savings scale with the number of socket poll events the application processes."
I assume (probably incorrectly) that using CURLMNOTIFY_INFO_READ somehow allows to minimize the number of curl_multi_info_read() calls, but
if the CURLMNOTIFY_INFO_READ notification handler still needs to call curl_multi_info_read(), I don't see how it can do that because the client still needs to call curl_multi_info_read() equal to the number of completed transfers.
But I can see that CURLMNOTIFY_INFO_READ notification can help to eliminate curl_multi_info_read() calls completely if libcurl consumes the messages automatically when it calls CURLMNOTIFY_INFO_READ notification handler.
That would be a good optimization because the CURLMNOTIFY_INFO_READ notification essentially dispatches the transfer completion which client previously had to do by calling curl_multi_info_read().
So, I was thinking that maybe Stefan was talking about such optimization when he stated that the application "no longer needs to explicitly call curl_multi_info_read() in its run loop" and wanted to clarify that.
Thanks,
Dmitry
-----Original Message-----
From: Daniel Stenberg <daniel_at_haxx.se>
Sent: Saturday, November 8, 2025 1:40 AM
To: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Cc: Stefan Eissing <stefan_at_eissing.org>; Dmitry Karpov <dkarpov_at_roku.com>
Subject: [EXTERNAL] Re: Questions about new multi-handle notifications
On Fri, 7 Nov 2025, Dmitry Karpov via curl-library wrote:
> But if this is the case, then the number of curl_multi_info_read()
> calls will be essentially the same as when using
> curl_multi_info_read() in the run loop because all the messages must
> be consumed explicitly regardless of whether CURLMNOTIFY_INFO_READ notification is used or not.
Without the notifications, you have to poll for messages.
Date: Mon, 10 Nov 2025 19:33:55 +0000
> With the notifications, you are told when there is a message to read.
I think even without CURLMNOTIFY_INFO_READ notification, the application is told when to read messages - when curl_multi_perform() returns.
It can accumulate more than one message if some transfers are completed almost simultaneously, but it should return as soon as there are messages for the client to process.
When I am reading what Stefan wrote before:
". An application using CURLMNOTIFY_INFO_READ no longer needs to explicitly call curl_multi_info_read() in its run loop.
While curl_multi_info_read() is not that expensive to call, especially event based libcurl applications had to invoke it *a lot* when processing many transfers. Especially when these transfers use many connections, and therefore sockets. The savings scale with the number of socket poll events the application processes.
While curl_multi_info_read() is not that expensive to call, especially event based libcurl applications had to invoke it *a lot* when processing many transfers. Especially when these transfers use many connections, and therefore sockets. The savings scale with the number of socket poll events the application processes."
I assume (probably incorrectly) that using CURLMNOTIFY_INFO_READ somehow allows to minimize the number of curl_multi_info_read() calls, but
if the CURLMNOTIFY_INFO_READ notification handler still needs to call curl_multi_info_read(), I don't see how it can do that because the client still needs to call curl_multi_info_read() equal to the number of completed transfers.
But I can see that CURLMNOTIFY_INFO_READ notification can help to eliminate curl_multi_info_read() calls completely if libcurl consumes the messages automatically when it calls CURLMNOTIFY_INFO_READ notification handler.
That would be a good optimization because the CURLMNOTIFY_INFO_READ notification essentially dispatches the transfer completion which client previously had to do by calling curl_multi_info_read().
So, I was thinking that maybe Stefan was talking about such optimization when he stated that the application "no longer needs to explicitly call curl_multi_info_read() in its run loop" and wanted to clarify that.
Thanks,
Dmitry
-----Original Message-----
From: Daniel Stenberg <daniel_at_haxx.se>
Sent: Saturday, November 8, 2025 1:40 AM
To: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Cc: Stefan Eissing <stefan_at_eissing.org>; Dmitry Karpov <dkarpov_at_roku.com>
Subject: [EXTERNAL] Re: Questions about new multi-handle notifications
On Fri, 7 Nov 2025, Dmitry Karpov via curl-library wrote:
> But if this is the case, then the number of curl_multi_info_read()
> calls will be essentially the same as when using
> curl_multi_info_read() in the run loop because all the messages must
> be consumed explicitly regardless of whether CURLMNOTIFY_INFO_READ notification is used or not.
Without the notifications, you have to poll for messages.
-- / 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-11-10