Re: Getting a list of easy handles in a multi handle - possible?

From: Timothe Litt <litt_at_acm.org>
Date: Sat, 26 Aug 2023 15:05:51 -0400

On 26-Aug-23 14:27, Daniel Stenberg via curl-library wrote:
> On Sat, 26 Aug 2023, Richard W.M. Jones via curl-library wrote:
>
>> It seems like the multi "knows" what easy handles it contains already
>> (multi->easyp), so we shouldn't have to maintain this list ourselves.
>> However I couldn't see anything in the API to access this.
>
> That is correct. The list is not accessible from the outside.
>
> I am open to the idea of adding a function to export this knowledge.
>
>> Alternatively, could there be an operation which frees up the multi
>> handle and any also frees the easy handles that it contains?
>> (curl_multi_cleanup removes the easy handles from the multi, but
>> doesn't free them.)
>
> ...
>
>> Am I missing something or is this something that could be added?
>
> Something like this can absolutely be added, and it might even make a
> lot of sense.
>
> I think I personally would favor an approach that exports the list of
> easy handles, or perhaps just a way for an application to iterate over
> them all, rather than a more simple "close all easy handles the multi
> handle knows". Mostly because providing an iterator opens up for more
> use cases than "just" closing down nicely.
>
> Thoughts? Any proposals for how such an API would look like?
>
I'd support an iterator, since it doesn't require the caller to allocate
a buffer.  However, you want it to be thread-safe, which may mean that
curl has to allocate a buffer.

Something like void *it = curl_get_handle_iterator(multi);  it is
opaque, but internally is a struct with length, current index, buffer of
handles);  while( (handle  = curl_next_handle(it)) != NULL) {
curl_close(handle) }; curl_free_iterator( it);

To be thread-safe, you copy the handle list in get_handle_iterator
(under a lock).  If you think you don't need to be thread safe, you can
simply use the list & length in the multi handle.  But thread-unsafe
usually bites you eventually.

It should be legal to call curl_free_iterator without exhausting the list.

You could consider a next_matching(it, selector, arg) if there are some
common cases (e.g. finding handles open on a given host, with a given
URL, in a given state).  That saves calls if searching for a subset, but
may not be worth the complexity unless there are LOTS of handles in a
multi.  I'd wait for use cases...


Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.

-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Received on 2023-08-26