On Thu, 17 Mar 2005 23:04:16 +0100, "Martin v. Löwis" <[EMAIL PROTECTED]> 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 atomic. 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. Jeremy _______________________________________________ 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
