On Thu, 17 Mar 2005 17:13:05 -0500, Tim Peters <[EMAIL PROTECTED]> wrote: > [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.
Fair enough. I didn't consider Windows at all or other non-POSIX platforms. > > > 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? Universal newline reads and get_line() both lock the stream if the platform supports it. So I expect that they are atomic on those platforms. But it certainly seems safe to conclude this is a quality of implementation issue. Otherwise, why bother with the flockfile() at all, right? Or is there some correctness issue I'm not seeing that requires the locking for some basic safety in the implementation. > 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 Using a lock seemed like a good idea there and still seems like a good idea now :-). 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