On Thu, 10 Jul 2008, Josef Drexler wrote:

>> Any particular references that caught your eye as bad or misleading?
>
> Mainly the man page at http://curl.haxx.se/libcurl/c/curl_multi_socket.html
> suggests calling curl_multi_socket rather than curl_multi_socket_action in
> the description and the return value sections.

I went over it today and gave the entire man page a new hair cut.

>> Assuming you're using a rather recent libcurl version, I don't think you
>> need to call it again at all - but it would of course be good and useful to
>> really verify this and document it. And remove the ability for the return
>> code to happen.
>
> I was trying to not require too new a version, and if possible degrade
> gracefully in the presence of bugs. So even when it shouldn't return with
> CURLM_CALL_MULTI_SOCKET, in the event that it does the transfers should not
> stall.

To play that really safe you should call it again with the same socket, but be
prepared that it'll return error (in older libcurls) if that socket no longer
is in use!

> Ah, it was probably an old version then. I've compiled it with various
> versions to see how it worked, since insisting on the latest version is not
> really feasible.

I understand that, but the entire curl_multi_socket* system is not only one of
the newest parts of libcurl but also quite possibly one of the least tested
areas. Thus we've found and fixed rather annoying bugs not very long ago.

> See below. Essentially you must make sure not to remove events from a
> reopened FD of the same number, but you must still remove it from your event
> loop if it wasn't reopened after all.
>
> For select() based backends, it must be removed from the poll whether it was
> closed or not. But for epoll et.al. it can only be removed if it wasn't
> closed already. If it was closed, the syscalls will simply fail. But if it
> was closed and reopened, you'd screw up a different FD that now has the same
> number.

libcurl will always (barring bugs) tell the application when a socket has been
closed, even if the same socket is then immediately created and put to use
again. This is a bug we had very recently, we discussed it and agreed on this
description of reality and how it should behave.

Thus the application should not have to care about a socket being re-used or
not after a close/create.

> That's why closing an FD before letting the event loop know of that fact
> should be avoided if at all possible. In libcurl's case that means it's
> probably safe so long as it generates a CURL_POLL_REMOVE notification for all
> closed sockets before returning from curl_multi_socket_action.

Oh yes, it should always do those callback calls about CURL_POLL_REMOVE before
it returns.

-- 
  / daniel.haxx.se