[Twisted-Python] Re: plus mode was Re: how winnt fileops workandwhat to do about it

Paul G paul-lists at perforge.com
Sat Dec 31 18:50:24 EST 2005

----- Original Message ----- 
From: "James Y Knight" <foom at fuhm.net>
To: "Twisted general discussion" <twisted-python at twistedmatrix.com>
Sent: Saturday, December 31, 2005 6:12 PM
Subject: Re: [Twisted-Python] Re: plus mode was Re: how winnt fileops 
workandwhat to do about it

> On Dec 31, 2005, at 4:57 PM, Paul G wrote:
>> oh, it makes perfect sense to have a workaround in twisted, i'm not 
>> suggesting otherwise. however, it should be just that - a temporary 
>> workaround until cpython has a fix for the issue, because (outside  of 
>> the offending libc implementation), that is the right place to  fix it.
> As I wrote in the bug report:
>> It's not a python bug except perhaps that python should raise an 
>> exception.
>> Doing a read and write without a seek in between is illegal in C.
>> "ANSI C requires that a file positioning function intervene between 
>> output and
>> input, unless an input operation encounters end-of-file."

you stop quoting right at the relevant part (ie, where the difference 
between eg glibc and msvcrt comes in):

"(If this condition is not met, then a read is allowed to  return
       the result of writes other than the most recent.)"

does msvcrt do this? no. moreover, msvcrt needs an *fsetpos()*/fseek() and 
an *fflush()* (as per cory), whereas glibc will take fseek() or *fgetpos()*. 
this means that calls resulting in synchronization in glibc and msvcrt are 
different, with glibc sticking to ansi c and msvcrt deviating.

there is an obvious deviation both from ansi c and from glibc usage.

moreover, none of this seems to be necessary with glibc in practice (and 
cpython seems to not be doing it or suggesting it in the docs), since this 
test doesn't fail on linux. different results given the same input is a bug, 

let us step back for a second: the problem rears its head in a file object 
"being returned from the open() method of a FilePath
object". the user has no way to know that he should be syncing the stream, 
primarily because he's being given a 'File', not a 'File stream'. either 
these issues should be listed in the docs, or taken care of underneath, 
keeping a File a black box. from a design point of view, the stream is an 
implementation detail - exposing it is ugly.

a matter of how you view it though.


More information about the Twisted-Python mailing list