[Python-Dev] thread semantics for file objects

[Jeremy Hylton]

On Thu, 17 Mar 2005 23:57:52 +0100, "Martin v. Löwis"
<martin at v.loewis.de> wrote:
> Remember, you were asking what behaviour is *documented*, not what
> behaviour is guaranteed by the implementation (in a specific version
> of the implementation).

Martin,

I think you're trying to find more finesse in my question than I ever
intended.  I intended to ask -- hey, what are the semantics we intend
in this case?  since the documentation doesn't say, we could improve
them by capturing the intended semantics.

> > Also, there are other operations that go to the trouble of calling
> > flockfile().  What's the point if we don't provide any guarantees?
> 
> Because nobody cares about guarantees in the documentation. Instead,
> people care about observable behaviour. So if you get a crash due to a
> race condition, you care, you report a bug, the Python developer agrees
> its a bug, and fixes it by adding synchronization.

As Tim later reported this wasn't to address a crash, but to appease a
pig headed developer :-).  I'm surprised by your claim that whether
something is a bug depends on the person who reviews it.  In practice,
this may be the case, but I've always been under the impression that
there was rough consensus about what constituted a bug and what a
feature.  I'd certainly say its a goal to strive for.

It sounds like the weakest intended behavior we have is the one Tim
reported:  "provided the platform C stdio wasn't thread-braindead,
then if you had N threads all simultaneously reading a file object
containing B bytes, while nobody wrote to that file object, then the
total number of bytes seen by all N threads would sum
to B at the time they all saw EOF."  It seems to me like a good idea
to document this intended behavior somewhere.

Jeremy