Re: Questions about new multi-handle notifications

[Stefan Eissing via curl-library]

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