Daniel Stenberg wrote:
> >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.

In principle, it's a little more efficient to just close() the socket,
than to remove it from epoll first and then close it. It saves a
system call. I guess that's one reason why epoll does that.

But with many other mechanisms, you must remove the descriptor. I'm
not aware of any where you have to remove the descriptor before
calling close(), but they might exist.

Assuming they don't exist, though, perhaps you could add
CURL_POLL_REMOVE_CLOSED, meaning the descriptor has been closed?
epoll callbacks would do nothing; others would do the same as for
CURL_POLL_REMOVE.

> >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.

The CLOSE_WAIT state is for sockets which have received FIN from the
remote side, but not been closed by the local application. It implies
a socket file descriptor is still open.

If the socket has been closed by libcurl, it should not be possible
for it to be in the CLOSE_WAIT state. Are you sure the socket isn't
dup'd to another file descriptor somewhere?

-- Jamie
Received on 2007-02-23