On Fri, 30 Jan 2009, Patrick Scott wrote:

>> All easy handles must be closed with curl_easy_cleanup() and the multi
>> handle with curl_multi_cleanup().
>
> I do call curl_easy_cleanup for each handle that finishes. What if I
> can't call curl_multi_cleanup for a long time? Do those dangling
> connections stick around until I do?

Yes. The connections are either closed after use or cached in the multi
handle.

> Where are they stored until they are cleaned up if they are not in the cache
> (I'd like to do some hacking of my own around parallel connections and
> pipelining)?

An easy handle is the "owner" of the connection until the transfer is done,
and then it is handed back to the cache (which is kept in the multi handle by
default when you use that). If the connection didn't fit the cache due to size
restrictions it will instead get closed and all resources associated with it
are freed.

>> The curl_multi_perform() and curl_multi_socket*() functions all return the
>> number of "active" transfers which is that number.
>
> I can cap the number of requests I give to curl but how does pipelining
> change that? Let's say I want to have a max of 5 simultaneous connections
> with each connection able to pipeline its requests (if possible). How can I
> make sure that I limit the number of connections to 5 without limiting the
> number of requests?

Oh, that is a very good question. Pipelining breaks the 1:1 assocation between
requests (easy handles) and connections so yes when pipelining is enabled it
isn't currently possible to figure out the number of connections using the
API. I'm open to suggestions on how we can expose this information to apps!

-- 
  / daniel.haxx.se