[Python-Dev] thread semantics for file objects (original) (raw)

stelios xanthakis sxanth at cs.teiath.gr
Sat Mar 19 03:21:45 CET 2005

Jeremy Hylton wrote:

On Thu, 17 Mar 2005 16:25:44 -0500, Aahz <aahz at pythoncraft.com> wrote:

On Thu, Mar 17, 2005, 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 just want to know what semantics are intended. If the documentation wants to say that the semantics are undefined that okay, although I think we need to say more because some behavior has been provided by the implementation for a long time.

I think that when two threads write to the same fd without syncronization, the result is not deterministic anyway. In the case they are reading from the same fd, even worse! (and therefore the input cannot be useful to any serious algorithm)

Python (libc in fact) just guarantees that there will be no crashes and corruption of data if the read/write functions are reentered. But ensuring that readline/writeline/etc is atomic would probably be a waste of resources protect the input/output for a case where the data is as good as random noise anyway.

So I think aahz is right.

Stelios

More information about the Python-Dev mailing list