Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!rpi!zaphod.mps.ohio-state.edu!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: <10269@hoptoad.uucp>
Date: 16 Feb 90 00:53:33 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> <10193@hoptoad.uucp> <1528@smurf.ira.uka.de>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 51

In article <1528@smurf.ira.uka.de> urlichs@smurf.ira.uka.de writes:
>< 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.

>I just wonder why, in the synchronous case, I get a "Please insert the disk"
>error, while in the async case (and even when calling PBxxx(PB,TRUE) from my
>main event loop or something) I do in fact get PB.ioResult = volOfflinErr.
>
>Something must be going on here. It can't be interrupts, since the System
>could simply stick the request to bring up the alert into the deferred task
>manager queue or something. Anyone in the know ?

The deferred task manager queue also runs at the interrupt level
(remember, interrupt level 0 is still the interrupt level if you're
fielding code from an interrupt), and came years after the current file
system implementation anyway.  Obviously the system is (wisely) leery
of freezing the whole system at the interrupt level and waiting for the
user, who's slow as mountains.  Also, you could easily be locking out
the floppy driver at a high interrupt level; it's never a good idea to
sleep at the interrupt level.  So I imagine the way it gets around this
is to check the async bit in the trap word stored in the ioTrap field
of the parameter block, and simply returns an error if it's set,
reasoning that all interrupt-level code would be doing async requests.

>Could it possibly be because that system error alert is invalidating whatever
>was behind it, which definitely would move memory? (Such invalidation could of
>course be deferred until the next GetNextEvent, but this is not what's
>happening.)

That's an interesting question.  It must have a preallocated saved-bits
bitmap/pixmap to restore the screen.  Or not.  I just checked; SysError
is in fact on the list of traps that can move or purge memory.  But
can't this alert come up in response to any operation on an offline
volume, not just open?  Yes, according to IM IV-92.  So this could
happen in response to *any* file system operation, practically.
Christ.  But the system error chapter spells out exactly what SysError
does, and it doesn't say anything about allocating heap memory or
saving bits.  I doubt it would, since it will often be called when a
heap is corrupted.  So *something* is wrong here; either all the file
system traps should be on the list, or SysError shouldn't be.

Isn't there some file system internals guru from Apple reading this
confusion who can help?
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com

"The government of the United States is not, in any sense, founded
 on the Christian religion." -- George Washington