[Python-Dev] thread semantics for file objects

Jeremy Hylton jhylton at gmail.com
Thu Mar 17 23:15:49 CET 2005

On Thu, 17 Mar 2005 23:04:16 +0100, "Martin v. Löwis"
<martin at v.loewis.de> wrote:
> 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

I'm surprised that it does not, for example, guarantee that reads and
writes are atomic, since CPython relies on fread and fwrite which are

Also, there are other operations that go to the trouble of calling
flockfile().  What's the point if we don't provide any guarantees?
<0.6 wink>.  If it is not part of the specified behavior, then I
suppose it's a quality of implementation issue.  Either way it would
be helpful if the Python documentation said something, e.g. you can
rely on readline() being threadsafe or you can't but the current
CPython implementation happens to be.

readline() seemed like an interesting case because readlines() doesn't
have the same implementation and the behavior is different.  So, as
another example, you could ask whether readlines() has a bug or not.


More information about the Python-Dev mailing list