Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!dewey.soe.berkeley.edu!oster
From: oster@dewey.soe.berkeley.edu (David Phillip Oster)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Think C 4.0 questions
Message-ID: <34242@ucbvax.BERKELEY.EDU>
Date: 11 Feb 90 23:58:00 GMT
References: <10682@bsu-cs.bsu.edu> <1968@cbnewsk.ATT.COM> <10111@hoptoad.uucp> <90039.151841CXT105@PSUVM.BITNET> <10160@hoptoad.uucp>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster)
Organization: School of Education, UC-Berkeley
Lines: 23

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.

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

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

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

Never? Well, hardly ever.