[Jeremy Hylton] > Are the thread semantics for file objecst documented anywhere?
No. At base level, they're inherited from the C stdio implementation. Since the C standard doesn't even mention threads, that's all platform-dependent. POSIX defines thread semantics for file I/O, but fat lot of good that does you on Windows, etc. > 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. I wouldn't consider this as more than CPython implementation accidents in the cases it appears to apply. For example, in universal-newlines mode, are you sure f.read(n) always maps to exactly one fread() call? > I'm less sure what guarantees, if any, the other methods attempt to > provide. I don't believe they're _trying_ to provide anything specific. > For example, it looks like concurrent calls to writelines() will interleave > entire > lines, but not parts of lines. Concurrent calls to readlines() provide insane > results, but I don't know if that's a bug or a feature. Specifically, if > your file has a > line that is longer than the internal buffer size SMALLCHUNK you're likely to > get parts of that line chopped up into different lines in the resulting > return values. And you're _still_ not thinking "implementation accidents" <wink>? > If we can come up with intended semantics, I'd be willing to prepare a > patch for the documentation. I think Aahz was on target here: NEVER, NEVER access the same file object from multiple threads, unless you're using a lock. And here he went overboard: And even using a lock is stupid. ZODB's FileStorage is bristling with locks protecting multi-threaded access to file objects, therefore that can't be stupid. QED _______________________________________________ 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