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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to