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