RFR: 7118373: (se) Potential leak file descriptor when deregistrating at around the same time as an async close

[Rob McKenna]

Hi folks,

Webrev:
http://cr.openjdk.java.net/~robm/7118373/webrev.00/

In a multi-threaded environment if thread a) cancels a SelectionKey and 
then closes a SocketChannel (for example) we can run into a problem if 
another thread (b) calls Selector.select() just after 
AbstractInterruptibleChannel.close() starts running. When this happens, 
open has been set to false but implCloseChannel() has not yet executed.

If thread b) starts running at this point the select() will kill() the 
socket by way of the deregister queue. Since 
implCloseSelectableChannel() will then proceed to dup2 this fd we're 
left with a leaking socket as the ST_KILLED has already been set so our 
subsequent call to SocketChannelImpl.kill() will simply return.

The call to kill() from AbstractPollSelectorImpl.implDereg() is 
necessary to properly deal with SelectableChannels whose 
reader/writerThread's were blocked in IO during a call to close().

The fix resolves this problem by checking that we haven't already killed 
this SelectableChannel before we attempt to dup2 its fd.

     -Rob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120416/e07498e0/attachment.html