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

[Markus KARG]

On Sun, 1 Aug 2021 08:24:13 GMT, Markus KARG <github.com+1701815+mkarg at openjdk.org> wrote:

>>> The modified code found in [4b501b2](https://github.com/openjdk/jdk/commit/4b501b205c6f1c48bbc82d7a154aed3fc41b1a20) should be safe from infinite loops, as it checks the actual file length in each iteration (even if this costs us one more `synchronized` per iteration).
>> 
>> 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.
>
> @AlanBateman Did I recap the sum your comments correctly, is the above conclusion what you wanted to tell me? Shall I proceed with one of the two solutions outlined in the "...2:2 matrix..." section of my answer *or* shall I wait until you had a deeper look?

Asserting blocking mode for *both* sides (source and target) in https://github.com/openjdk/jdk/pull/4263/commits/fc38eae44de9e16468d33bd2ebab6502c92b4860.

Eliminated the resulting duplicate code in https://github.com/openjdk/jdk/pull/4263/commits/4a0d7cf74ee7e35aa0448df4b5ea4c5e3113ece6.

Do you see more problems we need to solve?

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

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