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