RFR: 8351458: (ch) Move preClose to UnixDispatcher

[Alan Bateman]

On Tue, 11 Mar 2025 04:21:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Network channels in blocking mode, and the NIO based SocketImpl, have to deal with async close when there are threads blocked on the channel. Virtual threads blocked on the channel need to be unparked. On Unix systems, platform threads blocked on the channel require the file descriptor to be dup'ed to a special file descriptor and the threads signalled.
>> 
>> There is a bit of duplication in the implementation of the 5 channels, and in the SocketImpl. In addition, there is discussion on net-dev about an issue in AIX that will require allowing for signals to be queued (the current implementation does not require OS to support queuing of signals).
>> 
>> We refactor this code so that the "prepare for close" is in one place, UnixDispatcher.
>
> src/java.base/share/classes/sun/nio/ch/NativeDispatcher.java line 83:
> 
>> 81:     final void preClose(FileDescriptor fd, long reader, long writer) throws IOException {
>> 82:         if (NativeThread.isVirtualThread(reader) || NativeThread.isVirtualThread(writer)) {
>> 83:             int fdVal = JIOFDA.get(fd);
> 
> Hello Alan, previously, in the case of `DatagramChannelImpl`, the `fdVal` was a `final` that was determined when the channel was constructed. Now, that `fdVal` gets determined as and when needed and I see that `FileDescriptor` allows this underlying value to be changed/reset. Is there anything practical to consider here in context of a `fdVal` that has been reset in the `FileDescriptor`?

repairSocket doesn't change fd/fdVal, instead they will be connected to a new socket if the method succeeds (or the old socket if it fails).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23956#discussion_r1988574631