On Sun, 1 Aug 2021 08:24:13 GMT, Markus KARG <github.com+1701815+mk...@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
