On Tue, 18 Feb 2014, Jeff King wrote:
I'm not clear whether you mean by this that it is _expected_ in my test
program for curl not to reuse the connection. Or that curl may simply have
to do a little more work, and it is still a bug that the connection is not
Okey, I checked this closer now and this is the full explanation to what
happens. It seems to work as intended:
It's all about where the connection cache is held by libcurl. When you create
a multi handle, it will create a connection cache that will automatically be
shared by all easy handles that are added to it.
If you create an easy handle and make a curl_easy_perform() on that, it will
create its own connection cache and keep it associated with this easy handle.
When first using an easy handle within a multi handle it will use the shared
connection cache in there as long as it is in that multi handle family, but as
soon as you remove it from there it will be detached from that connection
Then, when doing a fresh request with easy_perform using the handle that was
detached from the multi handle, it will create and use its own private cache
as it can't re-use the previous connection that is cached within the multi
We can certainly teach git to use the multi interface, even when doing a
single blocking request.
For connection re-use purposes, that may make a lot of sense.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html