[Python-Dev] thread semantics for file objects

["Martin v. Löwis"]

Jeremy Hylton wrote:
> It sounds like the weakest intended behavior we have is the one Tim
> reported:  "provided the platform C stdio wasn't thread-braindead,
> then if you had N threads all simultaneously reading a file object
> containing B bytes, while nobody wrote to that file object, then the
> total number of bytes seen by all N threads would sum
> to B at the time they all saw EOF."  It seems to me like a good idea
> to document this intended behavior somewhere.

The guarantee that "we" want to make is certainly stronger: if the
threads all read from the same file, each will get a series of "chunks".
The guarantee is that it is possible to combine the chunks in a way to
get the original contents of the file (i.e. not only the sum of the
bytes is correct, but also the contents).

However, I see little value adding this specific guarantee to the
documentation when so many other aspects of thread interleaving
are unspecified.

For example, if a thread reads a dictionary simultaneous to a write
in another thread, and the read and the write deal with different
keys, there is a guarantee that they won't affect each other. If they
operate on the same key, the read either gets the old value, or the
new value, but not both. And so on.

Writing down all these properties does little good, IMO. This includes
your proposed property of file reads: anybody reading your statement
will think "of course it works this way - why even mention it".

Regards,
Martin