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.

---
** [bugs:#1355] Socket callback with CURL_POLL_REMOVE is too late**
**Status:** open
**Created:** Mon Apr 07, 2014 10:08 PM UTC by Constantin Baranov
**Last Updated:** Sat Apr 12, 2014 11:46 AM UTC
**Owner:** Daniel Stenberg
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.
---
Sent from sourceforge.net because curl-tracker@cool.haxx.se is subscribed to https://sourceforge.net/p/curl/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/curl/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.