curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. 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 himself.

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

From: Timothe Litt <>
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.

Received on 2023-08-26