On Mon, 16 Jun 2008, Phil Blundell wrote:

>> o it needs to do Curl_disconnect() on the connections, not just conn_free().
>> The lib/url.c:Curl_ch_connc() function should give lots of clues
>
> Thanks for the feedback. I couldn't immediately figure out how to make
> Curl_disconnect() work for connections that weren't associated with any easy
> handle; it seemed that conn->data just pointed off into oblivion in that
> case, which led to a crash somewhere in the hostcache code. Can you give me
> any further hints on that?

Ah right... This is actually quite a tricky problem, as for example the FTP
disconnect code requires a conn->data present and this new close function can
in fact be called when there is _no_ SessionHandle struct left allocated. In
the current code that cannot happen.

I think re-arranging code to not depend on conn->data isn't really a feasable
idea, so instead we should probably try getting a SessionHandle to use for the
disconnect. I'm thinking we can just make one for the close case, or possibly
get one that is currently left added to the multi handle, and restore it back
to the original state once all the idle connections are closed.

>> An alternative approach is of course to do the entire timeout-check and
>> closing of idle connections internally. That solves the "calling it too
>> often" problem and it also helps us from adding a new function (new
>> functions are a lot more trouble than just new setopt options).
>
> Yah, that was my first thought in fact, but it seemed like it would be
> rather harder to implement this way. You'd need to either arrange for the
> application to call curl_multi_perform() at the right moment or do something
> with alarm(), and neither of those seem entirely straightforward.

But the app is already calling curl_multi_perform() at the right moment for
the transfers, right? So it would only be a matter of make
curl_multi_timeout() return the correct time, and let curl_multi_perform() do
the checks and the closes when the time has come. Or did I misunderstand?

We already have a fairly sophisticated timer system for each socket libcurl
knows about, and that can probably be used for this too. (And it works fine
even for very large amounts of connections, like up to and above 10000 of
them...)

I realize my comments took your "little hack" and turned it into a more
advanced function that is no longer little, but I'm afraid I can't see how to
implement it that small and yet fully and properly functional!

-- 
  / daniel.haxx.se