8223353: (ch) Change channel close implementation to not wait for I/O threads

[Alan Bateman]

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