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

[Alan Bateman]

On Sat, 15 Apr 2023 12:28:51 GMT, Markus KARG <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 281:
>> 
>>> 279:                             if (!wsc.isBlocking())
>>> 280:                                 throw new IllegalBlockingModeException();
>>> 281:                             return transfer(rbc, wbc);
>> 
>> This introduces the potential for deadlock as lock ordering is not specified for the transferXXX methods. Note that this same issue is problematic for some of the optimisations at the lower level in FileChannel too. We'll need to think about this topic.
>
> 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.

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

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