multiple file objects for some file?

[Bengt Richter]

On Sun, 27 Jul 2003 13:17:50 -0400, "Tim Peters" <tim.one at comcast.net> wrote:

>[Gary Robinson]
>> For some code I'm writing, it's convenient for me to have multiple
>> file objects (say, 2 or 3) open on the same file in the same process
>> for reading different locations.
>>
>> As far as I can tell, there is no problem with that but I thought it
>> might be a good idea to ask here just in case I'm wrong.
>
>Provided they're "ordinary" on-disk files (not, e.g., sockets or pipes
>wrapped in a Python file object), that should be fine.  Each file object has
>its own idea of the current file position, and they'll all (of course) see
>the same data on disk.
>
>You can get in deep trouble if the file mutates, though.  Python's file
>objects are wrappers around C's streams, and each C stream has its own
>buffers.  So, for example, a mutation (a file write) made via one file
>object won't necessarily update the buffers held by the other file objects
>(it depends on how your platform C works, but I don't know of any that
>automagically try to update buffers across multiple streams open on the same
>file), and then reading via some other file object may continue to see stale
>data (left over in its buffer).
>
>For example, I bet this program will fail on your box before a minute
>passes:
<snip>
>
How about using mmap? Would that be a safe way to share (assuming you take care
of any logical ordering requirements for mutation/access)?

Do you have to flush every time you write (i.e., for sharing sync purposes,
not to guarantee persistence)?
Is there any difference re sharing issues between file vs slice spellings of updates?
Is anything guaranteed atomic?

Regards,
Bengt Richter