Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: FSWrite moving memory? (was Re: Think C 4.0 questions)
Message-ID: <10193@hoptoad.uucp>
Date: 12 Feb 90 11:47:06 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>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 60

In article <34240@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP
(David Phillip Oster) writes:
>> 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
>semaphoring to properly lock important data structures so that your disk
>will not be scrambled by interrupt level access.

Uh, David, you know I have the greatest respect for you, but would you
mind providing some substantiation for this astounding claim?  The
basic data structure, the file system request queue, is properly locked
to make sure that no two requests can try to get at the file system at
the same time.  None of the internal file system code allocates any
memory, and the only reentrant code is that which tacks the parameter
blocks onto the queue and takes them off the front -- and that is
indeed locked properly, by Enqueue and Dequeue.  The file system always
has been and always will be callable from the interrupt level.

>In addition, the mac
>uses a B-Tree catalog to manage file extents. Where do you thing it is
>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.

No, this is a definite miss.  The files grow on disk.  The entire files
do not have to be, and frequently are not, in RAM.  That's one of the
advantages of a B-tree structured index -- even if you have to resolve
every level of the index with disk fetches, there are still not many
fetches and it goes pretty fast.  No memory is *ever* allocated by the
file system using the Memory Manager.  Even the cache is preallocated,
and managed in an interrupt-friendly way.

>(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.)

If it's been losing you any sleep, you may now rest easy....

>>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?

This is another definite miss.  It's actually a system error alert, as
stated in IM II-80 and IV-92.  System error alerts are described in the
system error alert table, a non-relocatable, pre-allocated, and
pre-initialized structure.  System error alerts don't move any memory
under any circumstances, and they don't use resources.
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com

"The above opinions and suggestions have absolutely nothing to do with
 the little fat man putting crisp $100 bills in my pocket."
    -- Alan Vymetalik