I've noticed that SOCKETFUNCTION is called to POLL_REMOVE the socket
from watched set after the socket was already closed by curl
internally. This can cause problems with applications based on
epoll(). In case application calls fork and closes the filedescriptor
before it is removed from epoll set then epoll_wait will still report
events for that desciptor, even it was already closed in this process.
See question 6 in Questions and answers section of man 7 epoll for
better explanation.

I've attached example which shows epoll_ctl(DEL): Bad file descriptor
error in SOCKETFUNCTION. The internal close can be also checked by
strace.

I think I've identified the code path. It all starts in
Curl_disconnect. At first Curl_conncache_remove_conn unlinks easy
handle from connectdata structure then conn_free is called. conn_free
calls Curl_closesocket which calls Curl_multi_closed. However
Curl_multi_closed expects there is still easy handle associated so it
does nothing (not calling SOCKETFUNCTION). Control is returned to
Curl_multi_closed where socket is closed. Later the SOCKETFUNCTION is
called probably from singlesocket function.

Maybe it helps. I don't feel confident enough to touch the code myself.

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html