multiple file objects for some file?
bokr at oz.net
Sun Jul 27 20:29:41 CEST 2003
On Sun, 27 Jul 2003 13:17:50 -0400, "Tim Peters" <tim.one at comcast.net> wrote:
>> 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
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?
More information about the Python-list