RFR: 8305744: (ch) InputStream returned by Channels.newInputStream should have fast path for ReadbleByteChannel/WritableByteChannel [v3]

Markus KARG duke at openjdk.org
Sun Apr 16 17:58:31 UTC 2023


On Sun, 16 Apr 2023 08:37:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> IIUC the JRE already has the same problem in *other* locations, so wouldn't it make sense to merge the current PR as-is (to gain its benefit already in the upcoming LTS release) and postpone the discussion about possible deadlocks into a separate PR which then covers *all* those existing problematic code locations as a whole? Because I do not see why to withhold *just this* PR due to a problem existing *already* in the JRE.
>
>> IIUC the JRE already has the same problem in _other_ locations, so wouldn't it make sense to merge the current PR as-is (to gain its benefit already in the upcoming LTS release) and postpone the discussion about possible deadlocks into a separate PR which then covers _all_ those existing problematic code locations as a whole? Because I do not see why to withhold _just this_ PR due to a problem existing _already_ in the JRE.
> 
> Indeed, the issues of async close of the source/target during transfer, and the potential for deadlock with transfer between bidirectional streams is mostly a lower level concern for methods like FileChannel.transferXXX. It may be that we have to specify an ordering that higher level participants (ChannelInputStream.transferTo) would need to follow.

I do agree.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13387#discussion_r1167987831


More information about the nio-dev mailing list