wieser@cs-sun-fsd.cpsc.ucalgary.ca (Bernhard Wieser) (10/25/90)
Greetings; I am in the process of writing a 'background' task. Really, I am writing a VBL task. I wondering what problems could occur if I do what IM says not to, and use routines which use the memory manager. IM says you have to worry about handles being dereferenced. If you lock the handles you use, and clean up your stuff when done, can you safely use routines which call the memory manager Please e-mail me, wieser@cpsc.ucalgary.ca or BSWieser@uncamult.bitnet, with any help/hints. Even just to say hi (so I know news is working). Bernie (No signature, no pain)
dvlmfs@cs.umu.se (Michael Forselius) (10/26/90)
In article <1990Oct25.025224.23414@cpsc.ucalgary.ca> wieser@cs-sun-fsd.cpsc.ucalgary.ca (Bernhard Wieser) writes: > >Greetings; > >I am in the process of writing a 'background' task. Really, I am writing >a VBL task. I wondering what problems could occur if I do what IM >says not to, and use routines which use the memory manager. [... stuff deleted] This question makes me think of a 'trick' that I've thought of but never had the time or need to implement! If this is OK then you could move memory as you wish at interrupt (VBL) time. To explain this technique I'll use some pseudo language to clarify what I am thinking about. I suppose that the main use of this, IF it works of course, would be in an INIT/cdev. First of all we need to allocate a block of memory that`s resident. We could do this by: 1. Expanding the system heap (TMON). 2. Allocate a block in the system heap, as almost all INIT's/cdev`s do. 3. Subtract the amount of memory required from BufPtr, i.e. moving BufPtr downwards (also TMON). Then we would use InitApplZone(ourMemoryBlock,...,...,...) to initialize this block as an application heap zone. When we are called during some autovectored interrupt then we would save the current application zone, set the current zone to the one that we've made. Then we should (theoretical) be able to call almost any trap even if they could cause the zone to be purged/moved/compacted. This due to the fact that NewPtr,NewHandle,... MUST work WITHIN the current zone (this is a truth with modification since you could call NewPtrSys but this is no problem since YOU are supposed to know what you are doing). Then when we are finished with whatever we were doing we simply restores the zone and execution can continue. Some code to describe this could be: At INIT time: ... BufPtr = BufPtr - reqAmount ourMemoryBlock = BufPtr ... zone = InitApplZone(ourMemoryBlock,masters,...) ... At interrupt time: ... saveZone = TheZone ;this is the current heap zone TheZone = ourZone ... TheZone = saveZone .... This should work, shouldn't it? If not - please let me know and explain the reason why you think this approach might fail. Oh, remember that you'll have to finish your code before the next interrupt occurs otherwise the'll have the wrong zone to play with!... but seriously do you really want your VBL to take >1 Ticks! Thanx for reading this far - Have a Nice Day! > >Please e-mail me, wieser@cpsc.ucalgary.ca or BSWieser@uncamult.bitnet, >with any help/hints. Even just to say hi (so I know news is working). Hi Bernie! > >Bernie >(No signature, no pain) +---------------------------------------------------------+ | Michael Forselius Internet: dvlmfs@cs.umu.se | |---------------------------------------------------------| | Ever heard of 'Pirate Purgatory' !?! - tough one though | +---------------------------------------------------------+ No pain, no gain... -- +---------------------------------------------------------+ | Michael Forselius Internet: dvlmfs@cs.umu.se | |---------------------------------------------------------| | Ever heard of 'Pirate Purgatory' !?! - tough one though |
mitchell@tci.UUCP (Rob Mitchell) (10/26/90)
wieser@cs-sun-fsd.cpsc.ucalgary.ca (Bernhard Wieser) writes: >Greetings; >Please e-mail me, wieser@cpsc.ucalgary.ca or BSWieser@uncamult.bitnet, >with any help/hints. Even just to say hi (so I know news is working). >Bernie >(No signature, no pain) "HI"
oster@well.sf.ca.us (David Phillip Oster) (10/28/90)
D e v e l o p magazine, issue 4, p.374 says, Scott Williams writes:
InitZone should have calls to GetZone and SetZone around it, like this:
THz savedZone = GetZone();
InitZone(nil, kNumDfltMasters, limitPtr, zonePtr);
SetZone(savedZone);
----------- end quote.
since InitZone sets the current zone to be the new zone, and when we are
creating a provate zone for a VBL, we don't want the private zone to be the
current zone.
--
-- David Phillip Oster - Note new signature. Old one has gone Bye Bye.
-- oster@well.sf.ca.us = {backbone}!well!osterlippin@wish-bone.berkeley.edu (The Apathist) (10/30/90)
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
kaufman@Neon.Stanford.EDU (Marc T. Kaufman) (10/30/90)
In article <1990Oct30.052411.21527@agate.berkeley.edu> lippin@math.berkeley.edu writes:
-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.
Right on. I know of at least one VBL task that has tried to to a HeapSpace
check while the memory manager was moving things about. (This was a Screen
Dimmer program. I am starting to believe that there are way too many VBL and
interrupt tasks that don't understand why one should stay away from the
memory manager when they are run).
Marc Kaufman (kaufman@Neon.stanford.edu)lefty@twg.com ("Lefty") (11/03/90)
In article <1990Oct25.025224.23414@cpsc.ucalgary.ca> wieser@cs-sun-fsd.cpsc.ucalgary.ca (Bernhard Wieser) writes: > I am in the process of writing a 'background' task. Really, I am writing > a VBL task. I wondering what problems could occur if I do what IM > says not to, and use routines which use the memory manager. > > IM says you have to worry about handles being dereferenced. If you lock the > handles you use, and clean up your stuff when done, can you safely use > routines which call the memory manager It's a _bad_ idea. A _really_ _bad_ idea. The basic problem is that your VBL task is called at interrupt level. This could occur WHILE THE MEMORY MANAGER IS IN THE MIDST OF SHUFFLING MEMORY! Trying to allocate, deallocate, lock, unlock, etc. would quite possibly not work reliably in this context, and could well crash your system. In short, in a VBL task (or anything else that happens in an interrupt context) DO NOT call anything which directly or indirectly calls the Memory Manager. You can use pointers to nonrelocatable blocks, you can use handles which were locked in another context, but that's about it. -- Lefty (lefty@twg.com) "And you may ask yourself, DoD # 0152 'How do I work this?'"