RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v6]

[Markus KARG]

On Sun, 1 Aug 2021 07:46:36 GMT, Markus KARG <github.com+1701815+mkarg at openjdk.org> wrote:

>>> I need to look at it closely but I suspect this introduces a potential overflow. Also if output stream is backed by a SocketChannel configured non-blocking then FC::transferTo may return 0 so I assume there is a potential infinite loop there too. I suspect the eventually patch will need have to make use of the blockingLock to prevent the underlying channels from being changed to non-blocking during the transfer.
>> 
>> I need to confess that my NIO knowledge is not deep enough to follow you closely, so I trust on your advice how to go on from here.
>
>> I suspect the eventually patch will need have to make use of the blockingLock to prevent the underlying channels from being changed to non-blocking during the transfer.
> 
> The blocking lock now is used since https://github.com/openjdk/jdk/pull/4263/commits/f4485d5b6a3b5c471feff5642dfef0fc747d3fac to prevent this.

> Also can you can check that IllegalBlockingModeException is thrown for the case ch is a SelectableChannel configured non-blocking and the destination is a FileChannel?

Do we really only have to check this in the particular case of `FileChannel` destinations?

And don't we have to assert blocking mode for *destination* channels, too (just like `ChannelOutputStream::writeFully` does)?

As this results in an 2:2 matrix of possibilities (src is selectable nor not, dst is selectable or not) it might be easier to do *only the blocking checks* in `transferTo` but let it call something like `transferFromSelectableToNonSelectable` in turn *or* to wrap *each* implementation of `transferTo` in a wrapper like `executeInBlockingMode((src, dst) -> transferTo(src, dst))`...?

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

PR: https://git.openjdk.java.net/jdk/pull/4263