[
https://issues.apache.org/jira/browse/ARROW-2835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16825258#comment-16825258
]
Antoine Pitrou commented on ARROW-2835:
---------------------------------------
I see two other ways around this:
1) As soon as ReadAt or WriteAt is called, change the internal file state so
that any implicitly-positioning operation (such as Read, Write or Tell) fails
until Seek is called first.
or 2) Have an internal "positioning" lock that ensures that we can have several
ReadAt or WriteAt calls simultaneously, but that implicitly positioning
operations wait for the last *At call to end and to restore the file pointer.
I'm not sure how easy #2 is, but should be doable.
> [C++] ReadAt/WriteAt are inconsistent with moving the files position
> --------------------------------------------------------------------
>
> Key: ARROW-2835
> URL: https://issues.apache.org/jira/browse/ARROW-2835
> Project: Apache Arrow
> Issue Type: New Feature
> Components: C++
> Reporter: Dimitri Vorona
> Priority: Major
> Fix For: 0.14.0
>
>
> Right now, there is inconsistent behaviour regarding moving the files
> position pointer after calling ReadAt or WriteAt. For example, the default
> implementation of ReadAt seeks to the desired offset and calls Read which
> moves the position pointer. MemoryMappedFile::ReadAt, however, doesn't change
> the position. WriteableFile::WriteAt seem to move the position in the current
> implementation, but there is no docstring which prescribes this behaviour.
> Antoine suggested that *At methods shouldn't touch the position and it makes
> more sense, IMHO. The change isn't huge and doesn't seem to break anything
> internally, but it might break the existing user code.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
