[
https://issues.apache.org/jira/browse/OAK-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13829633#comment-13829633
]
Jukka Zitting commented on OAK-956:
-----------------------------------
I think the key to the disagreement here is about the definition of "blocking"
in the {{available()}} contract.
It seems like the {{FileInputStream}} interprets blocking in the narrow sense
of potential deadlocks, and thus treats the contents of local files as always
available even though potentially a bit slow to access. From that perspective
it would be reasonable to always return {{length - position}} as the number of
available bytes from a binary stream in Oak. A binary might be slow to access,
but all those bytes are guaranteed to eventually be read regardless of what
other threads are doing.
The alternative interpretation (used by practically all literature on
non-blocking IO) is broader, treating an operation as blocking if it can result
in the current thread suspending itself until some external event occurs. From
that perspective the current implementation is correct as it only returns a
non-zero value when it can guarantee the immediate return of the next
{{read()}} call.
> SegmentStream doesn't implement the method available()
> ------------------------------------------------------
>
> Key: OAK-956
> URL: https://issues.apache.org/jira/browse/OAK-956
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
> Reporter: Antonio Sanso
> Priority: Minor
>
> org.apache.jackrabbit.oak.plugins.segment.SegmentStream doesn't implement
> the method available()
> {code}
> Value.getStream().available()
> {code}
> will always return 0
--
This message was sent by Atlassian JIRA
(v6.1#6144)
