On Tue, Feb 18, 2014 at 08:13:16AM +0100, Daniel Stenberg 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 program: > > 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... :-/ You are talking about the NTLM fix here, right? I think there is still an unrelated issue with curl_multi preventing connection reuse, but I'm not sure from what you say below... > >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(). Thanks for the clarification. That was my guess from reading it, but given that it wasn't working as expected, I wondered if we were violating the rules. I saw the documentation fix you just pushed; it looks reasonable to me. > 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... 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 reused. We can certainly teach git to use the multi interface, even when doing a single blocking request. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html