8223353: (ch) Change channel close implementation to not wait for I/O threads
Alan Bateman
Alan.Bateman at oracle.com
Sun May 5 19:00:05 UTC 2019
I'd like to refactor the SelectableChannel close implementations so that
the close methods don't wait for I/O operations to abort when closing a
channel in blocking mode.
As I'm sure we all know here, closing a channel is complicated because
it requires coordinating with threads doing I/O operations. It also
requires coordinating with selection operations as the channel may be
registered with one or more Selectors. As things currently stand,
closing a channel in blocking mode with threads blocked in I/O
operations involves:
1. pre-close (the dup2 trick to close the connection but not release the
file descriptor)
2. signal the threads in blocking I/O operations so that they abort with
EINTR
3. wait for the threads to complete/abort the I/O operation
4. close the file descriptor (if not registered with a Selector - not
usually possible with channels configured in blocking mode but there are
convoluted scenarios to consider).
For comparison, the non-blocking case is a simple lock/unlock to ensure
that all I/O operations have completed and then closing the file
descriptor when not registered with a Selector. If registered with a
Selector then the close is deferred until its key is flushed from the
last Selector that it is registered with.
The proposed change is to eliminate #3 above and have the last I/O
operation to complete do the final close. This simplifies the close nd
means that I/O operation in progress and registered with Selector cases
are handled consistently. The change should not be observable to code
using these APIs as the pre-close will close the connection as before.
One benefit of the change is that is Thread.interrupt doesn't wait. A
second benefit is that we move stateLock in the implementations back to
being a built-in monitor, the condition object used to await/signal,
goes away.
The webrev with the proposed changes is here. The changes to stateLock
are purely mechanical, everything else is the refactor of the
implCloseSelectableChannel implementations.
http://cr.openjdk.java.net/~alanb/8223353/0/webrev/
-Alan
More information about the nio-dev
mailing list