RFR: 8310426: (ch) Channels.newInputStream transferTo cleanup
Alan Bateman
alanb at openjdk.org
Wed Jun 21 10:59:05 UTC 2023
On Tue, 20 Jun 2023 21:45:33 GMT, Markus KARG <duke at openjdk.org> wrote:
> IMHO the single benefit does not outweigh the multiple drawbacks.
SocketInputStream is already tightly coupled to the underlying SocketChannelImpl, it's not a ChannelInputStream. More is required here to avoid needing the use the blockingLock, make SIS.transferTo friendly to virtual thread usages, and also to coordinate with async close of a target FileChannel. With FileInputStream, the idea is the same, it will be able to coordinate with FileChannelImpl internals.
I think ChannelInputStream should be a simple input stream based on a readable channel. It can delegate to FileChannel.transferFrom when the target is an output stream that is based on a FileChannel but beyond that, I don't think we want it to have a close relationship with SocketChannelImpl or FileChannel internals.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/14566#issuecomment-1600623745
More information about the nio-dev
mailing list