curl-library
Re: Filedescriptor leak with curl_multi_socket API (CLOSE_WAIT)
Date: Fri, 23 Feb 2007 09:48:41 +0100 (CET)
On Fri, 23 Feb 2007, Pedro Larroy wrote:
> I'm using the curl_multi_socket API (debian's 7.15.5-1) with epoll for a
> university research project
I would recommend that you first upgrade to 7.16.1 since the curl_multi_socket
API is very new and we've made some significant bug fixes for it since 7.15.5.
In fact even since 7.16.1...
> and I have noticed a filedescriptor leakage using it. Perhaps I'm not using
> the api correctly, since it's a little tricky to get it right.
I agree that it is. If you have any ideas or feedback on what to improve in
the API or in the docs for the API, please tell us.
> When I recieve CURL_POLL_REMOVE I got epoll errors because apparently the fd
> was beeing already closed by curl, and thus removed of the epoll socket.
Hm. Yes, libcurl does close the socket by itself before it calls the socket
callback with CURL_POLL_REMOVE. It hasn't really struck me before, but I can
see how this could possibly become a problem if the underlying system like
epoll doesn't like it.
> I currently do nothing with CURL_POLL_REMOVE, but I have noticed that
> connections are left in CLOSE_WAIT state indefinitely. My question is that
> if this is my fault or is there a bug in curl.
It sounds like a libcurl bug then.
Any chance you can provide a small example that repeats the problem?
-- Commercial curl and libcurl Technical Support: http://haxx.se/curl.htmlReceived on 2007-02-23