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

[Florian Weimer]

* Alan Bateman:

> 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).

> 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.

What about resource consumption?

I think without #3, an application will have to synchronize with the
threads performing I/O on the channel being closed before it can safely
create a new channel, to ensure that the actual close (and resource
deallocation) happens before the creation of the new channel.

Based on your description of the current behavior, it should be possible
to create a new channel immediately after closing the old one because
the close call only returns after the scarce resource (the file
descriptor) has been deallocated.  I'm pretty sure this predictable
behavior would be lost.

Thanks,
Florian