dmmg1176@uxa.cso.uiuc.edu (David M Marcovitz) (02/20/91)
I vaguely remember seeing a reference to a list of functions that cause blocks of memory to be relocated. That is, I will need to call HLock before (and HUnlock) after these functions to keep certain blocks from being relocated. Can someone please tell me where I can find this list. Thanks. -- David M. Marcovitz | internet: marcovitz@uiuc.edu Computer-based Education Research Lab | dmmg1176@uxa.cso.uiuc.edu University of Illinois | novanet: marco / cca / cerl
bin@primate.wisc.edu (Brain in Neutral) (02/20/91)
From article <1991Feb20.042807.12553@ux1.cso.uiuc.edu>, by dmmg1176@uxa.cso.uiuc.edu (David M Marcovitz): > > I vaguely remember seeing a reference to a list of functions that > cause blocks of memory to be relocated. That is, I will need to call > HLock before (and HUnlock) after these functions to keep certain > blocks from being relocated. Can someone please tell me where I can > find this list. Thanks. It's safest to consider the list to be "all ToolBox calls", because although not every call *today* has the potential to cause memory to be moved, the list continues to expand over time. A function that's safe today might not be safe tomorrow. Sad but true. -- Paul DuBois dubois@primate.wisc.edu
nick@cs.edinburgh.ac.uk (Nick Rothwell) (02/20/91)
In article <1991Feb20.042807.12553@ux1.cso.uiuc.edu>, dmmg1176@uxa.cso.uiuc.edu (David M Marcovitz) writes: > I vaguely remember seeing a reference to a list of functions that > cause blocks of memory to be relocated. That is, I will need to call > HLock before (and HUnlock) after these functions to keep certain > blocks from being relocated. Can someone please tell me where I can > find this list. Thanks. I'm not sure the list is that useful, especially when you start running INITs which patch otherwise memory-safe traps. My approach: assume that *any* trap can move memory (well, except BlockMove, which I use to copy stuff between handles and the like). Patch BlockMove and I'll kill you... -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcsun!ukc!lfcs!nick ~~ ~~ ~~ ~~ Captain Waldorf has analogue filters. You do not. ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ Do not try to imitate them or any of their actions. ~~ ~~ ~~ ~~
keith@Apple.COM (Keith Rollin) (02/21/91)
In article <3947@uakari.primate.wisc.edu> bin@primate.wisc.edu writes: >From article <1991Feb20.042807.12553@ux1.cso.uiuc.edu>, by dmmg1176@uxa.cso.uiuc.edu (David M Marcovitz): >> >> I vaguely remember seeing a reference to a list of functions that >> cause blocks of memory to be relocated. That is, I will need to call >> HLock before (and HUnlock) after these functions to keep certain >> blocks from being relocated. Can someone please tell me where I can >> find this list. Thanks. > >It's safest to consider the list to be "all ToolBox calls", because >although not every call *today* has the potential to cause memory to >be moved, the list continues to expand over time. A function that's >safe today might not be safe tomorrow. Do you have any examples of this? I know that the System SW guys are pretty careful, for example, to not turn SetRect into a call that moves or purges memory. This should also be true for all other calls that are not listed as moving memory. By the way, David, the lists you are looking for are in the back of Inside Macintosh. -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions
lsr@Apple.com (Larry Rosenstein) (02/21/91)
In article <3947@uakari.primate.wisc.edu>, bin@primate.wisc.edu (Brain in Neutral) writes: > > It's safest to consider the list to be "all ToolBox calls", because > although not every call *today* has the potential to cause memory to > be moved, the list continues to expand over time. A function that's > safe today might not be safe tomorrow. I think this is being overly cautious. There's no way, for example, that SetRect, SetPt, HLock, BlockMore (to name a few) will ever move memory. Someone once mentioned that InitGraf used to be off the list, but now is on the list. Sure enough, it's not mentioned in volume 1 but is mentioned in volume 5. But are there other calls that were made unsafe? Larry
dmmg1176@uxa.cso.uiuc.edu (David M Marcovitz) (02/21/91)
> I vaguely remember seeing a reference to a list of functions that > cause blocks of memory to be relocated. That is, I will need to call > HLock before (and HUnlock) after these functions to keep certain > blocks from being relocated. Can someone please tell me where I can > find this list. Thanks. The list I was referring to can be found on page III-211 in Inside Mac. However, several people have informaed me that that list is constantly expanding, and in the right circumstances, any function call can cause memory blocks to be relocated. Thanks to those who responded. -- David M. Marcovitz | internet: marcovitz@uiuc.edu Computer-based Education Research Lab | dmmg1176@uxa.cso.uiuc.edu University of Illinois | novanet: marco / cca / cerl
timm@yoyodyne.ncsa.uiuc.edu (Tim McClarren) (02/21/91)
From article <1991Feb20.042807.12553@ux1.cso.uiuc.edu>, by dmmg1176@uxa.cso.uiuc.edu (David M Marcovitz): > > I vaguely remember seeing a reference to a list of functions that > cause blocks of memory to be relocated. That is, I will need to call > HLock before (and HUnlock) after these functions to keep certain > blocks from being relocated. Can someone please tell me where I can > find this list. Thanks. > Someone may have already responded to this, but IM Appendix B has a list of these routines (Routines That May Move or Purge Memory). ------------- Tim McClarren NCSA/UI
bin@primate.wisc.edu (Brain in Neutral) (02/21/91)
From article <49376@apple.Apple.COM>, by keith@Apple.COM (Keith Rollin): > Do you have any examples of this? I know that the System SW guys are > pretty careful, for example, to not turn SetRect into a call that moves > or purges memory. This should also be true for all other calls that are > not listed as moving memory. No, I don't have a specific example. I was thinking of the caution in the list in IM-V, for example, which says that many more routines move now than previously. I grant you that that doesn't say specifically that any *old* routines move memory now that didn't before, but it sounds pretty ominous to me. If Apple wants to come out and say: these routines don't move memory, *and they nevery will*, find. Until then, I'll stick by my statement that it's safest to assume that any ToolBox routine might. Is that over-cautious, or simply prudent? -- Paul DuBois dubois@primate.wisc.edu
bin@primate.wisc.edu (Brain in Neutral) (02/21/91)
From article <12178@goofy.Apple.COM>, by lsr@Apple.com (Larry Rosenstein): > I think this is being overly cautious. There's no way, for example, that > SetRect, SetPt, HLock, BlockMore (to name a few) will ever move memory. OK. Let Apple release an Official List of routines that Will Never Move Memory. > Someone once mentioned that InitGraf used to be off the list, but now is on > the list. Sure enough, it's not mentioned in volume 1 but is mentioned in > volume 5. But are there other calls that were made unsafe? The existence of a single call is enough to demonstrate the principle that it's reasonable to consider all ToolBox calls unsafe. If it's happened before, what's to prevent it from happening again? Personally, I think that it would be a *mistake* for Apple to guarantee that routine X does not now and never will move memory - that seems to be the kind of thing that would simply help Apple SW to be painted into a corner wrt future development. -- Paul DuBois dubois@primate.wisc.edu
lsr@Apple.com (Larry Rosenstein) (02/21/91)
In article <6484@skye.cs.ed.ac.uk>, nick@cs.edinburgh.ac.uk (Nick Rothwell) writes: > > I'm not sure the list is that useful, especially when you start running > INITs which patch otherwise memory-safe traps. If an INIT patches a trap, then it must follow the behavior of the trap it's patching, which includes whether or not it moves memory (as well as register usages, etc.). A patch to SetRect that moves memory will break a lot of code. Larry
mneerach@iiic.ethz.ch (Matthias Ulrich Neeracher) (02/21/91)
In article <6484@skye.cs.ed.ac.uk>, nick@cs.edinburgh.ac.uk (Nick Rothwell) writes: >In article <1991Feb20.042807.12553@ux1.cso.uiuc.edu>, dmmg1176@uxa.cso.uiuc.edu (David M Marcovitz) writes: >> I vaguely remember seeing a reference to a list of functions that >> cause blocks of memory to be relocated. [...] >I'm not sure the list is that useful, especially when you start running >INITs which patch otherwise memory-safe traps. [...] >Patch BlockMove and I'll kill you... Patch *any* memory-safe trap in a memory-unsafe way and I'll kill you. But do you have any examples of INITs doing trap patches this way ? Matthias -- Matthias Neeracher mneerach@iiic.ethz.ch "These days, though, you have to be pretty technical before you can even aspire to crudeness." -- William Gibson, _Johnny Mnemonic_
lippin@twinkies.berkeley.edu (The Apathist) (02/22/91)
In <3947@uakari.primate.wisc.edu>, bin@primate.wisc.edu (Brain in Neutral) writes: >> It's safest to consider the list to be "all ToolBox calls", because >> although not every call *today* has the potential to cause memory to >> be moved, the list continues to expand over time. A function that's >> safe today might not be safe tomorrow. In <12178@goofy.Apple.COM>, lsr@Apple.com (Larry Rosenstein) replies: > Someone once mentioned that InitGraf used to be off the list, but now > is on the list. Sure enough, it's not mentioned in volume 1 but is > mentioned in volume 5. But are there other calls that were made > unsafe? SysBeep was also memory-safe once, long ago. Nevertheless, one still shouldn't consider the list to contain all toolbox calls, for the simple reason that it's not practical. None of the calls on the list can be used at interrupt time, and interrupt tasks need *something* to work with. --Tom Lippincott lippin@math.berkeley.edu "Thank you for observing all safety precautions." --Dark Star
lsr@Apple.com (Larry Rosenstein) (02/22/91)
In article <3954@uakari.primate.wisc.edu>, bin@primate.wisc.edu (Brain in Neutral) writes: > > No, I don't have a specific example. I was thinking of the caution in > the list in IM-V, for example, which says that many more routines move > now than previously. I grant you that that doesn't say specifically that I interpreted this as saying that the total number of routines that move memory has increased substantially (and that you should look at the list in volume 5 as well as volume 3), not that some routines have "switched sides". Larry
urlichs@smurf.sub.org (Matthias Urlichs) (02/22/91)
In comp.sys.mac.programmer, article <12178@goofy.Apple.COM>,
lsr@Apple.com (Larry Rosenstein) writes:
<
< I think this is being overly cautious. There's no way, for example, that
< SetRect, SetPt, HLock, BlockMove (to name a few) will ever move memory.
<
While HLock probably won't move memory, you still can't use it at
interrupt time, so it's on "the list".
< Someone once mentioned that InitGraf used to be off the list, but now is on
< the list. Sure enough, it's not mentioned in volume 1 but is mentioned in
< volume 5. But are there other calls that were made unsafe?
<
InitGraf is probably a safe call to make unsafe. (Pun intended.)
The one call that I have some misgivings about is SetCursor.
Apart from some cute utilities rerouting it to SetCCursor for some cursor
shapes (I wrote one myself...), MPW started to call WaitNextEvent in its
patch. While this probably didn't break anything major, I remember people
being somewhat anxious about the possibility.
Personally, I don't use that list much. I keep a "safe to call" list in the
back of my head, and add to this any procedures/methods in my application
which won't move memory when I call them. I then forget to add these to
MacApp's keep-these-segments-resident list. :-( :-(
--
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330) \o)/orpheus@reed.UUCP (P. Hawthorne) (02/22/91)
Nick Rothwell writes:
. My approach: assume that *any* trap can move memory (well, except BlockMove,
. which I use to copy stuff between handles and the like).
I do this. So far so good. It makes it easier for me to write code, not
having to worry about getting the state of a handle recorded correctly at
each turn. I choose to assume the worst, and unlock my handles only on
special occasions, like when I want to repack my zone or something.
Others have pointed out, though, that it is possible to keep track if you
want to. Also, it has been pointed out that you should be able to depend on
the documentation about what moves memory, no matter what.
It strikes me that you need to be more aware of this in C than in Pascal,
since as I remember Think C, one must be familiar with the details of a given
trap's parameters and use pointers if appropriate.
Using Pascal, though, I find myself much more interested in what my
project ought to be doing than what my zone is doing, in general.
Distinctly different approaches, but equally valid depending on context.
I wonder sometimes if, when an object moves in memory, whether there is
any danger in using the methods of that object. Is there a chance that the
method would not be found because the object's type could not be found,
perhaps branching to some low memory location?
Must one be using locked handles in order to call methods?
orpheus@reed
"Don't tell me about politics. Our problem is the economics...
When you cannot have that which you don't own,
you scream and shout... all day long..." - New OrderLawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) (02/25/91)
Brain in Neutral writes in a message to All
BIN> If Apple wants to come out and say: these routines don't move
BIN> memory, *and they nevery will*, find. Until then, I'll stick
BIN> by my statement that it's safest to assume that any ToolBox routine
BIN> might.
BIN> Is that over-cautious, or simply prudent
I think that HLock and HUnlock are pretty safe...
Lawson
--
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English
Internet: Lawson.English@p88.f15.n300.z1.fidonet.orgLawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) (02/25/91)
P. Hawthorne writes in a message to All
PH> I wonder sometimes if, when an object moves in memory, whether
PH> there is any danger in using the methods of that object. Is there
PH> a chance that the method would not be found because the object's
PH> type could not be found, perhaps branching to some low memory
PH> location? Must one be using locked handles in order to call
PH> methods?
The Think compilers generate code that takes care of methods automatically.
(It was in the manual, so it's gotta be true!)
Lawson
--
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English
Internet: Lawson.English@p88.f15.n300.z1.fidonet.orgmurat@farcomp.UUCP (Murat Konar) (02/28/91)
In <12178@goofy.Apple.COM- lsr@Apple.com (Larry Rosenstein) writes: -In <3947@uakari.primate.wisc.edu-, bin@primate.wisc.edu (Brain in Neutral) writes: -- -- It's safest to consider the list to be "all ToolBox calls", because -- although not every call *today* has the potential to cause memory to -- be moved, the list continues to expand over time. A function that's -- safe today might not be safe tomorrow. - -I think this is being overly cautious. There's no way, for example, that -SetRect, SetPt, HLock, BlockMore (to name a few) will ever move memory. I tend to agree with this Brain fellow. It's just defensive programming. You can't count on all the INIT's that patch traps to do so in a way that preserves their 'safeness.' I do agree that SetRect et. al. will probably be safe forever. Also, I don't believe the list in Inside Mac or the X-Ref is entirely accurate. To wit: FindWindow is not listed as a routine that can move memory. However, in the course of its duties, FindWindow calls WDEFs. As far as I know, there are no restrictions on whether a WDEF can move memory. If my WDEF happens to move memory in its hit routine, then FindWindow bocomes a routine that can move memory. -Murat -- ____________________________________________________________________ Have a day. :^| Murat N. Konar murat@farcomp.UUCP -or- farcomp!murat@apple.com