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: Fri, 7 Nov 2025 19:49:39 +0000
> That is correct.
Not sure, if I understood your reply correctly.
Because if the documentation is correct, then the application still needs to use curl_multi_info_read() even if it uses CURLMNOTIFY_INFO_READ notification:
" The notification callback is then expected to read all available message, emptying the stack, so a subsequent addition triggers the notification again."
From my point of view, this means that the application needs to call curl_multi_info_read() in the notification callback to consume the message and clear the stack.
But you previously said:
> " An application using CURLMNOTIFY_INFO_READ no longer needs to explicitly call curl_multi_info_read() in its run loop ".
This kind of implies that the application doesn't need to call curl_multi_info_read() if it uses the CURLMNOTIFY_INFO_READ notification.
Or you meant that now instead of calling curl_multi_info_read() after curl_multi_perform(), it has to be called in the notification callback?
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.
> ... nothing that libcurl can automate
I was only referring to automatic consumption of CURLMSG_DONE messages when CURLMNOTIFY_INFO_READ notification is used,
so, the application will not have to call curl_multi_info_read() explicitly anymore if it uses the notification callback.
This is the major point of confusion to me - does the client still need to call curl_multi_info_read() if the CURLMNOTIFY_INFO_READ notification is used or not?
Based on your previous answer, I hope not, but then the documentation probably should clarify that as well.
Thanks,
Dmitry Karpov
-----Original Message-----
From: Stefan Eissing <stefan_at_eissing.org>
Sent: Friday, November 7, 2025 12:51 AM
To: Dmitry Karpov <dkarpov_at_roku.com>
Cc: libcurl development <curl-library_at_lists.haxx.se>
Subject: [EXTERNAL] Re: Questions about new multi-handle notifications
> Am 06.11.2025 um 21:54 schrieb Dmitry Karpov <dkarpov_at_roku.com>:
>
> Hi Stefan,
> Thanks a lot for explanations! But there is a still small confusion for me, which you can hopefully quickly resolve.
>
> You are saying:
>> An application using CURLMNOTIFY_INFO_READ no longer needs to explicitly call curl_multi_info_read() in its run loop.
>
> But the documentation (https://curl.se/libcurl/c/CURLMOPT_NOTIFYFUNCTION.html) says about CURLMNOTIFY_INFO_READ:
>
> "This notification happens whenever a message is added to an empty message stack in the multi handle and not for subsequent additions.
> The notification callback is then expected to read all available message, emptying the stack, so a subsequent addition triggers the notification again."
>
> When I read the documentation, it makes me think that even if client
> implements the notification callback it still needs to read the message (by calling curl_multi_info_read()) to consume it and make the message stack empty.
That is correct.
> Is it right? Or the message will be "consumed" automatically if the client subscribes to the CURLMNOTIFY_INFO_READ notifications?
> Could you please clarify that part?
>
> It would be great if client by subscribing to CURLMNOTIFY_INFO_READ notifications could completely eliminate the need to call curl_multi_info_read()).
> But then maybe the documentation should be corrected to make it clear.
A libcurl application needs still to process the easy handles that are DONE, e.g. removing them from the multi handle and clean them up. It may want to reuse them or do other things, which libcurl cannot make any assumptions about. Also the application may have its own resources (memory/files) that need cleaning up in such a case, nothing that libcurl can automate.
Cheers,
Stefan
>
> Thanks!
> Dmitry
>
>
> -----Original Message-----
> From: Stefan Eissing <stefan_at_eissing.org>
> Sent: Thursday, November 6, 2025 12:11 AM
> To: libcurl development <curl-library_at_lists.haxx.se>
> Cc: Dmitry Karpov <dkarpov_at_roku.com>
> Subject: [EXTERNAL] Re: Questions about new multi-handle notifications
>
>
>
>> Am 05.11.2025 um 23:18 schrieb Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>:
>>
>> I noticed that the 8.17.0 release now has multi-handle notifications
>> enabled via the curl_multi_notify_enable() API, and I have questions
>> about the CURLMNOTIFY_INFO_READ and CURLMNOTIFY_EASY_DONE notifications as I don't fully understand how to use them with curl_multi_perform().
>>
>> As I understand, the purpose of CURLMNOTIFY_INFO_READ event is to
>> allow to dispatch messages for completed transfers - call curl_multi_info_read() and then check CURLMSG_DONE, which is typically done after calling curl_multi_perform().
>>
>> I am wondering if this notification is called inside the
>> curl_multi_perform(), so it allows to dispatch transfer messages as soon as they are put into the message queue while curl_multi_perform() is running?
>> Or something else should be driving the multi-handle (not curl_multi_perform()) to trigger this notification?
>
> CURLMNOTIFY_INFO_READ is dispatched once the internal list of messages to read via curl_multi_info_read() is no longer empty. It is not dispatched if the list already has entries. CURLMNOTIFY_EASY_DONE is dispatched for every easy handle in a multi that is "done", irregardless of the info list state.
>
> The dispatching of multi notifications happens just before curl_multi_perform()/curl_multi_socket()/curl_multi_socket_action() returns. This allows the notification callback to add/remove easy handles just as it can be done "outside" such a call. 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.
>
> CURLMNOTIFY_EASY_DONE is probably not that interesting for many applications. It's more of a test balloon for transfer related notifications. We could think of others like it for CONNECTED, PAUSED/UNPAUSED, RETRYING, etc. We need feedback from libcurl applications to find out what is interesting in this space.
>
> Hope this helps. Happy to explain more.
>
> - Stefan
>
>> I am also confused about the CURLMNOTIFY_EASY_DONE notification.
>> The documentation says: " this notification is triggered when an easy handle has finished ".
>>
>> Isn't it kind of the same as CURLMNOTIFY_INFO_READ with CURLMSG_DONE handling or it has a totally different meaning?
>> Does it allow to skip calling curl_multi_info_read() with CURLMSG_DONE or the client still needs to call it even if it subscribes to this notification?
>>
>> If calling calling curl_multi_info_read() with CURLMSG_DONE is still
>> needed, then I think it is enough for client to use just the CURLMNOTIFY_INFO_READ with CURLMSG_DONE to know when some particular easy transfer is done, and there is no need to use the CURLMNOTIFY_EASY_DONE notification. Or I am missing something?
>>
>> It would be helpful to get some clarifications and explanations how these new cool features are expected to be used.
>>
>> Thanks,
>> Dmitry Karpov
>>
>> --
>> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
>> Etiquette: https://curl.se/mail/etiquette.html
>
Date: Fri, 7 Nov 2025 19:49:39 +0000
> That is correct.
Not sure, if I understood your reply correctly.
Because if the documentation is correct, then the application still needs to use curl_multi_info_read() even if it uses CURLMNOTIFY_INFO_READ notification:
" The notification callback is then expected to read all available message, emptying the stack, so a subsequent addition triggers the notification again."
From my point of view, this means that the application needs to call curl_multi_info_read() in the notification callback to consume the message and clear the stack.
But you previously said:
> " An application using CURLMNOTIFY_INFO_READ no longer needs to explicitly call curl_multi_info_read() in its run loop ".
This kind of implies that the application doesn't need to call curl_multi_info_read() if it uses the CURLMNOTIFY_INFO_READ notification.
Or you meant that now instead of calling curl_multi_info_read() after curl_multi_perform(), it has to be called in the notification callback?
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.
> ... nothing that libcurl can automate
I was only referring to automatic consumption of CURLMSG_DONE messages when CURLMNOTIFY_INFO_READ notification is used,
so, the application will not have to call curl_multi_info_read() explicitly anymore if it uses the notification callback.
This is the major point of confusion to me - does the client still need to call curl_multi_info_read() if the CURLMNOTIFY_INFO_READ notification is used or not?
Based on your previous answer, I hope not, but then the documentation probably should clarify that as well.
Thanks,
Dmitry Karpov
-----Original Message-----
From: Stefan Eissing <stefan_at_eissing.org>
Sent: Friday, November 7, 2025 12:51 AM
To: Dmitry Karpov <dkarpov_at_roku.com>
Cc: libcurl development <curl-library_at_lists.haxx.se>
Subject: [EXTERNAL] Re: Questions about new multi-handle notifications
> Am 06.11.2025 um 21:54 schrieb Dmitry Karpov <dkarpov_at_roku.com>:
>
> Hi Stefan,
> Thanks a lot for explanations! But there is a still small confusion for me, which you can hopefully quickly resolve.
>
> You are saying:
>> An application using CURLMNOTIFY_INFO_READ no longer needs to explicitly call curl_multi_info_read() in its run loop.
>
> But the documentation (https://curl.se/libcurl/c/CURLMOPT_NOTIFYFUNCTION.html) says about CURLMNOTIFY_INFO_READ:
>
> "This notification happens whenever a message is added to an empty message stack in the multi handle and not for subsequent additions.
> The notification callback is then expected to read all available message, emptying the stack, so a subsequent addition triggers the notification again."
>
> When I read the documentation, it makes me think that even if client
> implements the notification callback it still needs to read the message (by calling curl_multi_info_read()) to consume it and make the message stack empty.
That is correct.
> Is it right? Or the message will be "consumed" automatically if the client subscribes to the CURLMNOTIFY_INFO_READ notifications?
> Could you please clarify that part?
>
> It would be great if client by subscribing to CURLMNOTIFY_INFO_READ notifications could completely eliminate the need to call curl_multi_info_read()).
> But then maybe the documentation should be corrected to make it clear.
A libcurl application needs still to process the easy handles that are DONE, e.g. removing them from the multi handle and clean them up. It may want to reuse them or do other things, which libcurl cannot make any assumptions about. Also the application may have its own resources (memory/files) that need cleaning up in such a case, nothing that libcurl can automate.
Cheers,
Stefan
>
> Thanks!
> Dmitry
>
>
> -----Original Message-----
> From: Stefan Eissing <stefan_at_eissing.org>
> Sent: Thursday, November 6, 2025 12:11 AM
> To: libcurl development <curl-library_at_lists.haxx.se>
> Cc: Dmitry Karpov <dkarpov_at_roku.com>
> Subject: [EXTERNAL] Re: Questions about new multi-handle notifications
>
>
>
>> Am 05.11.2025 um 23:18 schrieb Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>:
>>
>> I noticed that the 8.17.0 release now has multi-handle notifications
>> enabled via the curl_multi_notify_enable() API, and I have questions
>> about the CURLMNOTIFY_INFO_READ and CURLMNOTIFY_EASY_DONE notifications as I don't fully understand how to use them with curl_multi_perform().
>>
>> As I understand, the purpose of CURLMNOTIFY_INFO_READ event is to
>> allow to dispatch messages for completed transfers - call curl_multi_info_read() and then check CURLMSG_DONE, which is typically done after calling curl_multi_perform().
>>
>> I am wondering if this notification is called inside the
>> curl_multi_perform(), so it allows to dispatch transfer messages as soon as they are put into the message queue while curl_multi_perform() is running?
>> Or something else should be driving the multi-handle (not curl_multi_perform()) to trigger this notification?
>
> CURLMNOTIFY_INFO_READ is dispatched once the internal list of messages to read via curl_multi_info_read() is no longer empty. It is not dispatched if the list already has entries. CURLMNOTIFY_EASY_DONE is dispatched for every easy handle in a multi that is "done", irregardless of the info list state.
>
> The dispatching of multi notifications happens just before curl_multi_perform()/curl_multi_socket()/curl_multi_socket_action() returns. This allows the notification callback to add/remove easy handles just as it can be done "outside" such a call. 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.
>
> CURLMNOTIFY_EASY_DONE is probably not that interesting for many applications. It's more of a test balloon for transfer related notifications. We could think of others like it for CONNECTED, PAUSED/UNPAUSED, RETRYING, etc. We need feedback from libcurl applications to find out what is interesting in this space.
>
> Hope this helps. Happy to explain more.
>
> - Stefan
>
>> I am also confused about the CURLMNOTIFY_EASY_DONE notification.
>> The documentation says: " this notification is triggered when an easy handle has finished ".
>>
>> Isn't it kind of the same as CURLMNOTIFY_INFO_READ with CURLMSG_DONE handling or it has a totally different meaning?
>> Does it allow to skip calling curl_multi_info_read() with CURLMSG_DONE or the client still needs to call it even if it subscribes to this notification?
>>
>> If calling calling curl_multi_info_read() with CURLMSG_DONE is still
>> needed, then I think it is enough for client to use just the CURLMNOTIFY_INFO_READ with CURLMSG_DONE to know when some particular easy transfer is done, and there is no need to use the CURLMNOTIFY_EASY_DONE notification. Or I am missing something?
>>
>> It would be helpful to get some clarifications and explanations how these new cool features are expected to be used.
>>
>> Thanks,
>> Dmitry Karpov
>>
>> --
>> 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-11-07