Mail Archives: djgpp-workers/1999/04/08/12:27:24
Bonjour
> On Tue, 6 Apr 1999, Alain Magloire wrote:
>
> > My Posix 1003.1, 1996 p 214(8.2.3.4) lines 363-367 says:
> > fflush:
> > The ffush() functions shall mark for update the st_ctime and st_mtime
> > fields of the underlying file if the stream was writable and if
> > buffered data had not been written to the file yet.
> > The underlying functions are write() and lseek().
>
> I'm actually interested in this part, because it seems to be relevant
> for the fflush/fsync problem in another thread. This excerpt seems
> like it requires fflush to also synchronize the filesystem, at least
> to some extent, which might suggest we *do* need to call fsync from
> inside fflush.
We agree that input stream is not always a keyboard, and output stream is
not always a file. In Unix, it can be a file, pipe, fifo, socket, ....
And on distributed system, the file may be on a different node.
fflush() doesn't require the implementor to call fsync() or fdatasync(), it just
says to call write() and lseek() to get the file index.
fflush() doesn't provide synchronize I/O it gives the same view of the world
for an application using this API(stdio). So if you use open()/write() mixed
with fopen()/fprintf() you'll have a problem or you got to fflush() at every
f*(FILE *) operation to have the same view of the data.
Synchronized I/O is very expensive, If one really want to synchronize
the state of a file an application should :
- do an fsync() or fdatasync() after every read() and write()
- use the I/O synchronisation flags with open() or fcntl()
O_SYNC, O_RSYNC, O_DSYNC
There is a difference between synchronous, asynchronous and synchronize.
{,a}synchronous the flag O_NONBLOCK is toggle, synchronize is usually the
O_*SYNC flags and *sync() force the same view of the data on the device.
Synchronize IO is mostly deal with on RealTime OS or big distributed database.
There is some things we take for granted/habits that influence the way
we understand certain library functions. That doesn't mean it is the right
thing to do IMO.
- stdin/stdout to be ttys or files.
Ouput stream: It happens when we do fflush(stdout) that we have a
synchronize view of the stream .i.e it appears on the screen. But on
may Un*x ttys follow a line discipline or use STREAMS (SVR4).
fflush(stream) on a file residing on a disk on the same node appears
to be instantaneous. Even if the file goes through the system I/O caches
or whatever scheme the OS is using.
If DJGPP wants to provide some of this extensions, that's fine. I just
think that adding this type of complexity and the knowledge of devices
to stdio API is not a good thing let the system calls (read()/write()/open()..)
handle it. That said it may be worth to provide some sort of extensions;
fflush(stdin) or whatever the DOS users are used too.
>
> However, the exact interpretation of ``shall mark for update'' is not
> clear to me. AFAIK, in Unix, this means that the system will not
> actually update the data untill something happens. What is the event
> that would trigger this update in this case?
>
``shall mark for update'' means that the inode will be updated/touch somewhow.
This is usually done via write(), a write() will update the inode fields for
the mtime and ctime etc .. And an other example is the difference between
fsync() and fdatasync(), fdatasync() will may not update the inode if nothing
was written, but fsync() will always ``mark for update''.
Buffer caches are a good thing, it improves I/O, you want to think twice
before using *sync() or O_*SYNC.
--
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!
- Raw text -