Path: utzoo!attcan!uunet!snorkelwacker!ira.uka.de!smurf!urlichs
From: urlichs@smurf.ira.uka.de
Newsgroups: comp.sys.mac.programmer
Subject: Re: FSWrite moving memory? (was Re: Think C 4.0 questions)
Message-ID: <1527@smurf.ira.uka.de>
Date: 13 Feb 90 19:56:00 GMT
References: <10682@bsu-cs.bsu.edu> <1968@cbnewsk.ATT.COM> <10111@hoptoad.uucp> <90039.151841CXT105@PSUVM.BITNET> <1510@smurf.ira.uka.de> <34240@ucbvax.BERKELEY.EDU>
Organization: University of Karlsruhe, FRG
Lines: 58

In comp.sys.mac.programmer, article <34240@ucbvax.BERKELEY.EDU>,
  oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes:
< In article <1510@smurf.ira.uka.de> urlichs@smurf.ira.uka.de writes:
< >In comp.sys.mac.programmer, article <90039.151841CXT105@PSUVM.BITNET>,
< >< 
< >Not in this case. All file system calls are supposed to be callable from
< >interrupt, and so they (as well as any patch sitting on them)_can't_ move
< >memory.
< 
< Wrong! Wrong! Wrong! The file system calls can not be called from
< interrupt level. Neither the SCSI manager, nor the file manager does the

The SCSI manager does not. That's true, and to be fixed in 7.0.

However, the file manager does. It has a global queue with file system
requests in it and only works on the first one. Since _Enqeue and _Dequeue
lock out interrupts while they run, there's your semaphoring.
And as long as nobody else uses the SCSI manager, there are no problems.
So I can just shout "Right! Right! Right!" here...

(NB: I was talking about the low-level file manager calls with async set to
TRUE. The high-level calls reduce to low-level calls with async=FALSE, which
obviously is not good when called from an interrupt.)

< semaphoring to properly lock important data structures so that your disk
< will not be scrambled by interrupt level access.  In addition, the mac
< uses a B-Tree catalog to manage file extents. Where do you thing it is

You can manage a B-tree easily without caring for its size. All you have to do
is to store a pointer to the next upper level in each node instead of
remembering them in memory..

< going to put that B-Tree? As the file gets large, the structures that
< describe where that file is on disk _must_ grow. This will move memory.
< (I wouldn't be so emphatic about it, but it might be _my_ hard disk that
< crashes as a result of running a program that has this error in it.)
< 
Sorry, but I had this server of mine run in interrupt level for hours, letting
three clients create folders, files, read them, write them, delete them again,
without any problems at all. (Expect numerous flames from people who try to
tell you that you don't seem to know what you're talking about.
Oops, that sounds too much like Tim Maroney -- sorry.)

< >Unfortunately, I wonder if they still could possibly move memory in the
< >synchronous case, which may not be called from interrupt.
< >If the disk to be written to isn't online, the Mac will display its nice
< >"Please insert the disk" alert. It would be interesting to know if this can
< >make any memory manager calls, and if so, in what heap.
< 
< Since these are just resources, they certainly will move memeory unless
< they've already been read in and locked in.  There is a system call:
< CanAlert(), to preread such things. Does your program call it?
< 
No. The routine is called CouldAlert(), and it's for ordinary alerts,
which the "Please insert disk" window is definitely _not_.

-- 
Matthias Urlichs