curl / Mailing Lists / curl-library / Single Mail



From: Deweloper <>
Date: Thu, 23 Mar 2017 01:15:34 +0100

On Thu, 23 Mar 2017 00:05:32 +0100 (CET)
Daniel Stenberg <> wrote:

> On Wed, 22 Mar 2017, Deweloper wrote:
> > Later I found this information by browsing the curl source code (inside the
> > body of Curl_getconnectinfo). Maybe it's worth including in the manual page
> Sounds like a good idea. You have any wording to suggest that would've helped
> you?

Well, I'm still trying to collect necessary information...

> A connection you've "taken over" from libcurl is tainted and libcurl can
> never again reuse that since the status and protocol of it are totally
> unknown.
> But I'm not sure this needs to be taken into account much. I think you can
> reuse an easy handle but it won't (shouldn't!) reuse the previous connection.
> > Isn't it allowed to call curl_easy_perform again on the same handle?
> It should be. I wonder if it isn't also actually okay to reuse an easy
> handle, contrary to what the documentation says...

If I understand correctly, a "connection" is an entity specific to implementation of libcurl, inaccessible by API and outside of scope of application's interest. Does "taking over a connection" mean taking ownership of the socket obtained by calling curl_easy_getinfo(CURLINFO_ACTIVESOCKET), including the need to close() it? I mean, won't libcurl never ever do any operation on the socket it returned to the application (especially closing it), apart when directed to do so by calling curl_easy_recv() or curl_easy_send()?

Now my app checks if curl_easy_recv or curl_easy_send returned something other than CURLE_OK and CURLE_AGAIN, or if curl_easy_recv returned zero length. In such cases it closes the socket provided earlier by CURLINFO_ACTIVESOCKET, then calls curl_multi_remove_handle, and some time later calls curl_multi_add_handle using the same easy handle.
Does this make sense?

Received on 2017-03-23