On Mon, 17 Feb 2014, Jeff King wrote:
Right; I'd expect multiple connections for parallel requests, but in this
case we are completing the first and removing the handle before starting the
second. Digging further, I was able to reproduce the behavior with a simple
Yeah, given your description I had no problems to repeat it either. Turns out
we had no decent test case that checked for this so in our eagerness to fix a
security problem involving "over-reuse" we broke this simpler reuse case. Two
steps forward, one step backward... :-/
The manpage for curl_multi_add_handle does say:
When an easy handle has been added to a multi stack, you can not
and you must not use curl_easy_perform(3) on that handle!
Does that apply to the handle after it has finished its transaction and been
removed from the multi object (in which case git is Doing It Wrong)?
No it doesn't. The man page should probably be clarified to express that
slightly better. It just means that _while_ a handle is added to a multi
handle it cannot be used with curl_easy_perform().
So yes, you can remove indeed it from the handle and then do
curl_easy_perform(). It works just fine!
Several internal caches are kept in the multi handle when that's used though,
so when getting the easy handle out after having used it with the multi
interface and then using it with the easy interface may cause libcurl to do a
little more work than if you would be able to re-add it to the same multi
handle do to the operation with that...
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