[Python-Dev] xreadlines : readlines :: xrange : range
Thu, 11 Jan 2001 23:22:40 -0500
> The locking prevents concurrent threads accessing the stream.
> But mixing reads and writes (without intervening fseek etc.) is
> illegal use of the stream, and the C standard allows them to be lax
> here, even if the program was single-threaded.
> In other words: the locking is so good that it serializes the
> sequence of reads and writes; but if the sequence of reads and
> writes is illegal, they don't guarantee anything.
We're never going to agree on this one, you know.
My definition of "bug" here has nothing to do with the std: something's "a
bug" if it's not functioning as designed. That's all. So if the
implementers would say "oops! that should not have happened!", then to me
it's "a bug". It so happens I believe the MS implementers would consider
this to be a bug under that defn. Multi-threaded libraries have to be
written to a much higher level than the C std guarantees (been there, done
that, and so have you), and this is specifically corruption in a crucial
area vulnerable to races. They have a timing hole! That's clear. If the
MS implementers don't believe that's "a bug", then I'd say they're too
unprofessional to be allowed in the same country as a multithreaded library
Your definition of "bug" seems to be more "I don't want it in Python's open
bug list, so I'll do what Tim usually does and appeal to the std in a
transparent effort to convince someone that it's not really 'a bug' -- then
maybe I'll get it off of Python's bug list".
I'm sure you'll agree that's a fair summary of both sides <wink>.