On Wed, 29 Jul 2009, Mohun Biswas wrote:

> Left to its own devices, libcurl prefers to keep socket connections open,
> which - given the above design - would result in the socket associated with
> the initialization handle being kept open for the entire run. Is this a
> problem?

Nope.

> Is there a chance something could time out and close the socket causing my
> app to fail?

Well, a timed out socket in the middle of a transfer will cause the transfer
to fail. But that's probably not what you're asking, right?

> I don't see anything in TFM about this so for now I'm being a wimp and
> setting CURLOPT_FORBID_REUSE after initialization, thus forcing a reconnect
> at finish time. I guess at the very least a file descriptor is freed up by
> doing it this way (probably not important). But will libcurl silently
> re-establish the socket connection if lost?

When you issue a new request, be it with easy or the multi interface, libcurl
will attempt to re-use an existing connection as far as possible. If there is
no existing, it creates a new one, or of the existing one it tries to re-use
is found to have been closed since last looked at, it will also create a new
one instead.

Thus, it is entirely transparent to the app wether the connection was re-used
or not.

> The overhead is only a small constant, and probably not critical, but I'd
> like to do the elegant thing, whatever that is.

The most elegant thing is IMHO to re-use the curl handles and let libcurl
figure out an existing connection to re-use as far as possible.

-- 
  / daniel.haxx.se