[
https://issues.apache.org/jira/browse/HDFS-6803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14092958#comment-14092958
]
Steve Loughran commented on HDFS-6803:
--------------------------------------
I'm very tempted to push for a lax model which says
# either the preads block or they are concurrent if the FS supports
# preads and classic (read@pos) reads may be concurrent or blocking
# getPos() may expose the position of a positioned read
I know #3 goes up against all the rules of hiding things, but think of this: if
we mandate that {{getPos()}} hides all intermediate positions on pread, then
any class which uses the base implementation of seek+read+seek will require
{{getPos()}} to be synced with the read, which implies that :
{{getPos()}} may block for an arbitrary amount of time if another thread is
attempting to perform a positioned read and is having some problem
communicating with the far end.
Is that something we really want? Is it something people expect?
> Documenting DFSClient#DFSInputStream expectations reading and preading in
> concurrent context
> --------------------------------------------------------------------------------------------
>
> Key: HDFS-6803
> URL: https://issues.apache.org/jira/browse/HDFS-6803
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: hdfs-client
> Affects Versions: 2.4.1
> Reporter: stack
> Attachments: DocumentingDFSClientDFSInputStream (1).pdf
>
>
> Reviews of the patch posted the parent task suggest that we be more explicit
> about how DFSIS is expected to behave when being read by contending threads.
> It is also suggested that presumptions made internally be made explicit
> documenting expectations.
> Before we put up a patch we've made a document of assertions we'd like to
> make into tenets of DFSInputSteam. If agreement, we'll attach to this issue
> a patch that weaves the assumptions into DFSIS as javadoc and class comments.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
