Re: fread/fwrite/fflush bug (Norm Green)
Re: fread/fwrite/fflush bug (Norm Green)
- Subject: Re: fread/fwrite/fflush bug (Norm Green)
- From: Terry Lambert <email@hidden>
- Date: Tue, 8 Jan 2008 16:00:59 -0800
On Jan 7, 2008, at 12:51 PM, David Hoerl wrote:
Date: Mon, 7 Jan 2008 09:49:19 -0800
From: Norm Green <email@hidden>
Subject: RE: fread/fwrite/fflush bug
...
Someone pointed out the fpurge() function. Calling fpurge() on the
reader
before the 2nd read fixes the problem.
This might be one fix for your code, but how about other code not
yet ported to OSX that is looking for "proper" behavior (making an
assumption here).
Reading the man page for fpurge, it says: "For input streams this
discards any input read from the underlying object but not yet
obtained via getc(3)...". I interpret this to mean the following
would fail (but not your example):
- writer writes say 1000 bytes
- reader is told to read one byte at location 0 (but fread gets a
buffer full)
- writer changes all the data - all 1000 bytes
- reader reads location 1, and gets old data (which it already had
in the buffer)
- reader keeps reading a byte at a time. When the internal buffer is
exhausted THEN it would start reading the actual file again, and get
a buffer of correct data.
Based on the man page, one could assume that the seek backwards
should cause the data in the buffer to get flushed as if fpurge was
called. Apparently fread looks to see if the requested bytes are
located in its buffer in all cases, and if so, uses them.
The presumption by the man page here is it's the same program doing
the reading and writing, and therefore the buffers are shared because
you are dealing with the same descriptor.
For other descriptors/buffers, you are effectively assuming a
distributed cache coherency for the data cached by the stdio
subsystem, which is not a valid assumption, under almost any
circumstances.
There's actually a stdio implementation that was done in university
research that uses mmap()'ed pages rather than local buffers, but it
pretty much never went anywhere outside of research because of the
performance penalties for anything but small files.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden