Updating existing JDK code to use InputStream.transferTo() (original) (raw)

Remi Forax forax at univ-mlv.fr
Wed May 13 23:06:41 UTC 2015

Hi Chris,

On 05/14/2015 12:40 AM, Chris Hegarty wrote:

On 13 May 2015, at 22:45, Remi Forax <forax at univ-mlv.fr_ _<mailto:forax at univ-mlv.fr>> wrote:

may return 0, is when len == 0. And it's never the case here. Unless, of course, some misbehaving implementation of InputStream is used. The other reason to have read that returns 0 is if the underlying channel is in non-blocking mode. A read on an InputStream created by Channels.newInputStream on a SelectableChannel may return 0 and the code will go in a loop until the SelectableChannel can read something. while(read() > 0) avoid that issue. Remi, is this right? I’d have to write a simple test to fully satisfy myself, but ChannelInputStream appears to put a SelectableChannel into blocking mode before reading, if it is non-blocking.

No, it seems, i'm wrong on that. I have taken a look to ChannelInputStream and SocketAdapter.SocketInputStream and both don't accept non-blocking SelectableChannel. Sorry for the noise.

The other things that may be a problem with this patch is that a lot of codes replaced by transferTo use either a bigger or a smaller size of buffer than transferTo. Given that we don't know if the buffer size is something important for a code or if the buffer size can be changed, i think it's better to split this patch in several parts and to send each parts to the right mailing list. You are probably right, anything that is not a like for like replacement with the transferTo implementation should have a thorough review from the appropriate component team. -Chris.

regards, Rémi

More information about the core-libs-dev mailing list