🚀 go-pugleaf

In article <2638@batcomputer.tn.cornell.edu> eacj@tcgould.tn.cornell.edu (Julian Vrieslander) writes:
>This certainly does give a nice speed increase, especially if you have
>2 Meg or more to run around in.  But I am hesitant to use RAM cache when
>I am debugging tricky code that is crashing a lot; I worry about losing
>source changes that have not been written from the cache out to disk.  
>
The RAM cache sure gets a lot of bad 'press'. I have used it with LSC
very happily for a LONG time and have survived MANY crashes with it with
absolutely NO loss of data. There was a lot of scare about it for awhile
because it's not write-thru. I don't have any official dope on this, but
from what I have been able to discover (mostly by just watching disk
activity), the cache is flushed to disk whenever FlushVol() is
called. If this is true then the RAM cache is no less safe than any-
thing else since the normal disk buffers are also only flushed when
FlushVol is called. IM recommends that you call FlushVol whenever you
close a file or after a Save, and I suspect LSC does this before Running
your application. (I have LSC set up to do auto saves before a Run.)
I believe ExitToShell and perhaps a few other routines also call FlushVol.

In summary, I have yet to figure out why the RAM cache is more dangerous
than the standard Mac disk-buffering. I have used it successfully for
nearly a year now and have never lost data because of it, though
I've crashed many, many times in many strange and interesting ways.

Robert Gardner