[Python-Dev] thread semantics for file objects

["Martin v. Löwis"]

Jeremy Hylton wrote:
>>>Are the thread semantics for file objecst documented anywhere?  I
>>>don't see anything in the library manual, which is where I expected to
>>>find it.  It looks like read and write are atomic by virtue of fread
>>>and fwrite being atomic.
>>
>>Uncle Timmy will no doubt agree with me: the semantics don't matter.
>>NEVER, NEVER access the same file object from multiple threads, unless
>>you're using a lock.  And even using a lock is stupid.
> 
> 
> I'm not looking for your permission or approval.

Literally, the answer to your question is "no". In fact, Python does not
specify *any* interleaving semantics for threads whatsoever. The only
statement to this respect is

"""
Not all built-in functions that may block waiting for I/O allow other
threads to run.  (The most popular ones (\function{time.sleep()},
\method{\var{file}.read()}, \function{select.select()}) work as
expected.)
"""

Of course, this says it works as expected, without saying what actually
is expected.

> I just want to know what semantics are intended.

But this is not what you've asked :-)

Anyway, expected by whom? Aahz clearly expects that the semantics are
unspecified, as he expects that nobody ever even attempts to read the
same file from multiple threads.

> If the documentation wants to say that
> the semantics are undefined that okay, 

Formally, there is no need to say that something is undefined. Not
defining anything is sufficient. So the semantics *is* undefined,
whether the documentation "wants" to say that or not.

 > although I think we need to say
 > more because some behavior has been provided by the implementation for
 > a long time.

That immediately rings the Jython bell, and perhaps also the PyPy
bell.

So if you want to say something, just go ahead. Before I make the
documentation want to say that, I would like to make it say more
basic things first (e.g. that stores to variables are atomic).

Regards,
Martin