curl-library
Re: Explicitly closing sockets
Date: Sun, 22 Mar 2009 09:58:49 -0700
On Mar 22, 2009, at 12:27 AM, Daniel Stenberg wrote:
> On Sat, 21 Mar 2009, Chad Monroe wrote:
>
>> Thanks for the quick response. The reason I continue to poll() on
>> sockets "not used by libcurl any longer" is because
>> curl_multi_fdset() returns them in the fd_set data even after the
>> connection has finished. I assume this is because libcurl leaves
>> the sockets open as denoted by the message:
>>
>> * Connection #0 to host 10.4.4.204 left intact
>>
>> I'm not sure if this is the intended behavior of curl_multi_fdset()
>> or if it's possibly a bug. If you think it's an issue I can
>> investigate further if you'd like.
>
> The fact that the connection is left open simply means that it'll be
> kept in the connection cache and thus is subject for a later re-use.
> curl_multi_fdset() should only ever return socket bit about sockets
> that are in active current use by an easy handle so if it truly
> returns info about a socket no longer used it is definately an error
> and if you can produce a sample app that shows this happening I'll
> be very interested!
>
> --
>
> / daniel.haxx.se
Hi Daniel,
I started writing a test program and discovered a bug in the code I
use to transform fd_set data into something poll() can use. I keep an
integer, curl_fd_max as returned by curl_multi_fdset(). I then scan
from 0 to curl_fd_max and add/remove descriptors to/from my local copy
of the fd_set struct and poll() as needed. The problem was when the
highest numbered descriptor closes. I'd never scan high enough to
remove it as curl_fd_max would be decreased.
The fix was simply to cache the last known curl_fd_max value, call
curl_multi_fdset, compare the old and new max values, then use the
largest. This ensures that high number descriptors no longer in use
get cleared.
With this fix in place, libcurl performs exactly as I'd expect, even
without the use of CURLOPT_FORBID_REUSE. Thanks for pointing me in the
right direction on this one!
-- Chad MonroeReceived on 2009-03-22