Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#1355 Socket callback with CURL_POLL_REMOVE is too late

closed-invalid
None
5
2014-06-15
2014-04-07
No

Sometimes curl closes a socket before notifying user via SOCKETFUNCTION. I caught this in a case when I want to terminate a transfer in the middle of downloading.

See attached source. I'd expect fcntl() don't fail. If it doesn't work (i.e. doesn't report fcntl error), change the URL to a bigger resource.

I'd like to let curl close its sockets, but I need to get CURL_POLL_REMOVE message when socket is still alive. Otherwise my network reactor goes crazy.

1 Attachments

Discussion

  • Thanks for your report.

    I understand what you want, but I'm not convinced this is what is guaranteed by this function. It informs you about changes to which sockets to wait for and what to wait actions for those sockets, it does not guarantee that it tells you before it closes them. (and it never did)

    So, I'm not at all convinced this is truly a "bug".

    Changing the code to actually do the callback before the socket is closed could be a worthy exercise still, but not swiftly done I'd say.

    A work-around could perhaps be to use the CURLOPT_CLOSESOCKETFUNCTION.

     
    • assigned_to: Daniel Stenberg
     
  • Yes, I may use CLOSESOCKETFUNCTION, but even then I have to do the trick delaying the actual close() call. Otherwise, as I already said, I get CURL_POLL_REMOVE notification for already closed socket. And really bad thing is that a new socket or other thing may be opened (in other thread) and takes over the old FD number. Even worse is if that new thing is added to the same network reactor used for curl.

     
  • Sorry, but why is that such a big deal? Sure when libcurl closes the fd another thread may get the same fd number (and do something with it), but the thread that invoked libcurl will be told about the removal from within the same call that closed the socket so this thread shouldn't be able to do a lot even though it'll have the old fd around for a little while too long.

    And I'm not arguing that this is the perfect functionality. I'm saying that we're acting as documented and as designed. I can see how an application such as yours would like a modified and improved behavior, but it really isn't just a small quick patch you're asking for - this will not be fixed/changed by me at least in the nearest future. You're most welcome to try to address this issue yourself and send a patch.

     
    • status: open --> pending-invalid
     
    • status: pending-invalid --> closed-invalid
     
  • Died. Closing.