Path: utzoo!utgpu!watserv1!watmath!att!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!ucsd!ucbvax!agate!wish-bone.berkeley.edu!lippin
From: lippin@wish-bone.berkeley.edu (The Apathist)
Newsgroups: comp.sys.mac.programmer
Subject: Re: More Mac Wierdness (Memory Mangler)
Message-ID: <1990Oct30.052411.21527@agate.berkeley.edu>
Date: 30 Oct 90 05:24:11 GMT
References: <1990Oct25.025224.23414@cpsc.ucalgary.ca> <1990Oct26.095921.24118@cs.umu.se>
Sender: usenet@agate.berkeley.edu (USENET Administrator)
Reply-To: lippin@math.berkeley.edu
Organization: Authorized Service, Incorporated
Lines: 29

Recently dvlmfs@cs.umu.se (Michael Forselius) wrote:
[a hack to allow the "may move or purge memory" routines to be used at
interrupt time: in brief, create a private heap zone and SetZone to it
for the duration of the interrupt task.]

I can think of three problems with this approach:

First, toolbox routines aren't limited to messing with the current
zone.  They might mess with the system heap, or with the heap
containing one of their parameters.

Second, many system data structures can be in an inconsistent state at
interrupt time.  For example, anything that's stored in a handle could
be caught in motion as memory is being shuffled.

Third, some toolbox routines (notably anything that draws) use global
variables in a non-reentrant manner.  So you can't call those, for
fear that the main process is in the middle of a call.

The last two problems run deeper than the memory manager.  In fact, I
suspect that some of the routines on the "may move or purge memory"
list in IM don't actually shuffle memory, but instead have these other
problems at interrupt time.

					--Tom Lippincott
					  lippin@math.berkeley.edu

	    "Thank you for observing all saftey precautions."
					--Dark Star