Shenjiaqi commented on code in PR #20860:
URL: https://github.com/apache/flink/pull/20860#discussion_r990609029
##########
flink-runtime/src/main/java/org/apache/flink/runtime/state/memory/ByteStreamStateHandle.java:
##########
@@ -148,7 +148,7 @@ public int read(byte[] b, int off, int len) throws
IOException {
index += bytesToCopy;
return bytesToCopy;
} else {
- return -1;
+ return len == 0 ? 0 : -1;
Review Comment:
> Thanks for pointing this out, after rethinking the semantics of `read()`,
I think changing the
[NoFetchingInput#readBytes()](https://github.com/apache/flink/blob/9d2ae5572897f3e2d9089414261a250cfc2a2ab8/flink-core/src/main/java/org/apache/flink/api/java/typeutils/runtime/NoFetchingInput.java#L115-L140)
is a better way to go.
>
> As
https://docs.oracle.com/javase/8/docs/api/java/io/FileInputStream.html#read--
explained,
>
> > Returns:
> > the total number of bytes read into the buffer, or -1 if there is no
more data because the end of the file has been reached.
>
> We should keep the semantics of `read()` consistent.
ByteStateHandleInputstream extends FSDataInputStream, which actually extends
InputStream. So I think we should refer to
https://docs.oracle.com/javase/8/docs/api/java/io/InputStream.html read(byte[]
b, int off, int len). In the doc says "If len is zero, then no bytes are read
and 0 is returned". I also refer to the implementation of
[InputStream#read](https://github.com/openjdk/jdk/blob/jdk-18+37/src/java.base/share/classes/java/io/InputStream.java#L278-L282),
it first make sure len <= b.length - off, then return 0 if len is 0, event if
off == b.length.
As for doc of FileInputStream, we should refer to read(byte[] b, int off,
int len) instead of read(), and it says "If len is not zero, the method blocks
until some input is available; otherwise, no bytes are read and 0 is returned."
So this change actually fix the semantic right.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]