Hi Chris,
On 05/14/2015 12:40 AM, Chris Hegarty wrote:
On 13 May 2015, at 22:45, Remi Forax <fo...@univ-mlv.fr
<mailto:fo...@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
