Path: utzoo!utgpu!watserv1!watmath!att!att!linac!uwm.edu!rpi!zaphod.mps.ohio-state.edu!mips!twg.com!lefty
From: lefty@twg.com ("Lefty")
Newsgroups: comp.sys.mac.programmer
Subject: Re: More Mac Wierdness
Message-ID: <8204@gollum.twg.com>
Date: 3 Nov 90 02:05:16 GMT
References: <1990Oct25.025224.23414@cpsc.ucalgary.ca>
Sender: news@twg.com
Organization: Interessengemeinschaft Maas-NeoTek
Lines: 26

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?'"