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: Stefan Eissing via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 6 Nov 2025 09:10:30 +0100
> 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: Thu, 6 Nov 2025 09:10:30 +0100
> 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-06