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