[net.micro.mac] Cache bit--retraction & questions

borton@sdcc3.UUCP (Chris Borton) (04/30/86)

From what I've read here and heard from CompuServe (via INFO-MAC aka mod.mac)
it sounds like I was mistaken about setting the cache bit.  Apparently a 
discussion on CompuServe resolved that it doesn't matter for normal cache
usage.  I am sorry if my blunder caused any worries or problems.

Re-evaluating it, I agree with Andrew Shebenaw's explanation that the bit is
for 'supercharging' applications.  On this matter Apple has said they will
provide information 'in the future.'  When will that be?

Next time I will do quantitative analysis rather than base assumptions upon
the fact that it seemed to go a lot faster.  The cache still raises plenty of
questions in my mind, however.  Will Apple publish the algorithm they use?
If so, when?  Are there hooks to implement another?  (Larry?)

A few people have made the observation that it is *not* a write-through
cache.  This surprised me somewhat, since it doesn't seem to be keeping with
Apple's 'safe' policy.  Then again, starting with Finder 4.1 I guess we are
*supposed* to Shut Down.  It still seems like quite an assumption...

If there is anyone with more information, please share it.  This is an area
of interest and thus far little available information.

-Chris
-- 
Chris Borton, UC San Diego Undergraduate CS; Micro Consultant, UCSD
borton@sdcsvax.UCSD.EDU || ...!{ucbvax,decvax,noscvax,ihnp4,bang}!sdcsvax!borton
"Was soll ich darauf sagen?"  "Nichts--das ist verboten!"

barad@brand.UUCP (Herb Barad) (05/05/86)

In article <3265@sdcc3.UUCP> borton@sdcc3.UUCP (Chris Borton) writes:
>
>A few people have made the observation that it is *not* a write-through
>cache.  This surprised me somewhat, since it doesn't seem to be keeping with
>Apple's 'safe' policy.  Then again, starting with Finder 4.1 I guess we are
>*supposed* to Shut Down.  It still seems like quite an assumption...

An earlier article that I posted stated that FastEddie2 has problems
using the cache.  I did not realize that the Apple cache was not a
write-through cache.  So the FastEddie2 problem is really Apple's.
You see, FastEddie2 will open a large (>32K) file in separate buffers,
each in its own window.  If you have the cache bit set and the cache
on (as I use to), the editing session will not be "safe" - that is,
many changes especially between buffers may not be saved properly.

Where is the cache handled?  The new ROM's?  Can a "write-through"
INIT patch be posted?
-- 


Herb Barad	[USC - Signal and Image Processing Institute]

USENET:		...!sdcrdcf!usc-oberon!brand!barad			or
		...!mcvax!seismo!sun!trwspf!brand!barad

ARPANET:	barad%brand@USC-ECL.ARPA

USMail:		Univ. of Southern California
		Powell Hall 306, MC-0272
		Los Angeles, CA 90089-0272
		phone: (213) 743-0911