[Python-Dev] thread semantics for file objects

[Jeremy Hylton]

On Thu, 17 Mar 2005 17:13:05 -0500, Tim Peters <tim.peters at gmail.com> 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