On Sat, 31 Jul 2021 17:33:50 GMT, Alan Bateman <al...@openjdk.org> wrote:
>>> 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? >> >> Done in >> https://github.com/openjdk/jdk/pull/4263/commits/8e2889fd6138d8aa8e308a1cd2aea3546a7c43a7, >> but honestly I'd kindly like to ask for a brief explanation why this has to >> be done. What actual bad effect would happen if I do not throw? > >> 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? ------------- PR: https://git.openjdk.java.net/jdk/pull/4263
