[ On Monday, May 28, 2001 at 11:51:43 (-0500), Lex Spoon wrote: ]
> Subject: Re: pending file primitives (EH?)
>
> Hmm, actually there are two kinds of #flush -- one that makes sure the
> data gets into the OS

I.e. empties any buffers in the VM....

> and one that makes sure the data gets onto the
> disk.  The latter is useful for high-reliability servers.  The function
> is called "sync" on Unix, but I prefer "uberFlush", or maybe
> "flushToDisk" depending on your mood.  :)

Using sync() is a bit of over-kill, and won't work on all platforms
(certainly it doesn't provide any guarantees at the time it returns!)
In fact it's generally considered bad manners for any application to
directly call sync() -- the system should be left to its own for this.

However fsync() [originally from 4.2BSD] "normally" has the desired
effect (though of course there are still no absolute guarantees).

To be really sure that all data is committed to stable storage as early
as possible it's usually best to use the O_SYNC flag on open() [if your
current target platform supports it, of course].  On some systems you
can even go completely nuts and combine in O_RSYNC to be sure that the
file's new access time is committed to stable storage before the read()
completes!  ;-)

The trick with O_SYNC is that it then allows a program using stdio to
use the normal stdio buffering as appropriate and to just call fflush(),
not only flush its stdio buffers but to also ensure any data written has
been been committed to stable storage if necessary.  It gives you the
best of both buffering and integrity all under the direct control of the
application.

Which reminds me.  An application doing fixed-record I/O with stdio will
usually want to adjust the stdio buffer to be some exact multiple of the
record size, especially if using O_SYNC since the last thing you want is
for stdio to flush a partial record out behind your back....

I don't know how this might all translate into smalltalk primitives, or
whether it maps up to FileStream or not.....

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods at acm.org>     <woods at robohack.ca>
Planix, Inc. <woods at planix.com>;   Secrets of the Weird <woods at weird.com>