title: Safe way to handle closure of sockets managed by epoll
body: <p>Using epoll_wait to manage multiple connections using multiple threads, there is a risk trying to release custom data associated with a closed socket.</p>
  
  <p>Consider the following scenario, where T is the custom data :</p>
  
  <ol>
  <li>Data is received, </li>
  <li>Because of 1, thread A deblocks from epoll_wait and processes the event (access T)</li>
  <li>At same time, another thread B, wants to close the connection</li>
  </ol>
  
  <p>Thread B can't assume that T can be safely deleted, eventhough the call to close will immediatly remove the socket from the epoll.</p>
  
  <p>I had the following standard idea :</p>
  
  <p>Maintain a variable within T that gets incremented each time a call to write/read returns EAGAIN, and gets decremented each time the socket is ready.
  When close is called, wait for that variable to go down to zero before deleting T.
  The issue I experienced is that if close is called, epoll_wait does not return an indication of a cancellation of previous calls to arm the socket.</p>
  
  <p>Anybody had this same problem ? How did you managed to overcome it ?</p>