Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Think C 4.0 questions
Message-ID: <10194@hoptoad.uucp>
Date: 12 Feb 90 12:06:59 GMT
References: <10682@bsu-cs.bsu.edu> <1968@cbnewsk.ATT.COM> <10111@hoptoad.uucp> <90039.151841CXT105@PSUVM.BITNET> <10160@hoptoad.uucp> <34242@ucbvax.BERKELEY.EDU>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 57

In article <10160@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>>I would hate to
>>think that I was supposed to start locking my handles before calling
>>BlockMove or TickCount or PBWrite (synchronously).  In real life,
>>that's not going to happen; there are many traps which clearly will
>>never move memory.

In article <34242@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP
(David Phillip Oster) writes:
>1.) Blockmove, since it is an O.S. trap requires glue to be callable by
>most high level language compilers. If the glue is in a not currently
>loaded segment, memory will move reading it in. (I know that you, Tim,
>know about this, I am including it for completeness.)

Yeah, I also mentioned the segment issue during this discussion.  In my
opinion, the best solution is to keep all trap glue in a never-unloaded
segment, preferably segment 1.

>2.) TickCount is one of the calls that is part of the Journaling system.
>If Journaling is on, then TickCount will make a Control() call on the
>journaling driver, which may do anything it wants, including i/o (such as
>writing the journal log out to disk.)  (Many version sof Apple's
>Imagewriter driver assume that TickCount() will not clobber A0. And it
>won't, unless journaling is on.)

Interesting point.  This is in fact what IM says (I-261-2), but I just
disassembled the TickCount routine in my SE's RAM and it doesn't take
any side trips under any circumstances; there is simply no way for it
ever to call Control.  Journaling is activated by setting a flag in low
memory, so TickCount doesn't get patched when journaling recording mode
is turned on.  Perhaps this implementation of the routine is part of
the replacement of the old journaling system by MacroMaker.

In any case, the journaling behavior of TickCount has been documented
since IM I, but TickCount has never made it onto any list of traps that
can move or purge memory.  Therefore, any journaling driver that
allocates memory when it receives a (hypothetical) TickCount control
call is broken.  I reserve the right to be incompatible with
third-party trap patches and miscellaneous add-ons that blatantly
ignore the rules....

Journaling drivers *can* do i/o, but i/o doesn't move memory.

>3.) PBWrite to the file manager may move memory, as I just discussed in an
>immediately previous message.

Unfortunately, that discussion was incorrect.

Happens to the best of us.

Who is it who's started running that great signature line -- "Only a
mediocre man is always at his best"?
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com

"Everything that gives us pleasure gives us pain to measure it by."
    -- The Residents, GOD IN THREE PERSONS