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.

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

Reply via email to