Re: Questions about new multi-handle notifications

> Am 05.11.2025 um 23:18 schrieb Dmitry Karpov via curl-library <[email protected]>:
> 
> 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.html