8223353: (ch) Change channel close implementation to not wait for I/O threads
Alan Bateman
Alan.Bateman at oracle.com
Tue May 7 13:58:58 UTC 2019
On 07/05/2019 14:35, Chris Hegarty wrote:
> :
> The changes to convert the stateLock back to using the built-in monitor
> of a private Object seem ok ( from what I can tell the changes seem to
> accurately anti-delta part of what was done in 8222774 [1] )
Yes although the non-trivial parts of JDK-8222774 are not changed.
>
> I'm trying to piece this together the other aspect of this change,
> close not waiting on I/O threads. To help better understand the change
> in behaviour, was it the changes for (8198562 & 8198754) [2], in
> Java 11, that resulted in socket channel `close` waiting on I/O threads
> to complete? Or something else ( I could be wrong as the code in this
> area has changed a few times ).
>
Right. When you close a channel (or socket) that has threads(s) blocked
on I/O operations then you have to coordinate the close with those
threads. We have two ways to do this. Both use preClose and signal to
ensure that threads commencing I/O operations will not block and threads
that are already blocked will get EINTR. The approaches differ on which
thread does the "final close" to release the file descriptor. With
classic networking the last thread to abort does the final close. With
NIO it was the same prior to JDK 11. The channels implementations were
mostly re-implemented in JDK 11 to separate the blocking/non-blocking
code paths and async close changed to wait for the blocking case. So
it's revisiting this so the last I/O operation to abort will do the
final close. Part of the motivation now is Thread.interrupt to avoid
that needing to wait. No change to non-blocking, the final close is
always deferred when registered with one or more selectors.
-Alan
More information about the nio-dev
mailing list