🚀 go-pugleaf

In article <43mrf6INN602@gambier.ugrad.cs.ubc.ca>, c2a192@ugrad.cs.ubc.ca
(Kazimir Kylheku) wrote:

>In article <wade-1809952212460001@f182-067.net.wisc.edu>,
>Wade E. Masshardt <wade@macc.wisc.edu> wrote:
>>In article <43kai7INNjvp@anvil.ugrad.cs.ubc.ca>, c2a192@ugrad.cs.ubc.ca
>>(Kazimir Kylheku) wrote:
>>>But if you lock down handles, you are fighting the OS in its efforts to
>>>eliminate fragmentation.
>>
>>Unless you have brain, in which case you lock the handle just before you
>>are going to use it, then unlock it as soon as you are finished.  Duh.
>
>My point that the whole thing is idiotic in the first place.
>
>The whole reason for locking handles is that you are going to yield the
>CPU, and don't want the block touched.  Before you get the CPU back, the

No, that is not the reason you lock handles.  The reason you lock handles
is that you are about to call a ToolBox routine *which might move
memory*.  There are quite a few of these routines that, in the course of
their execution, have to allocate some memory.  The routine they call to
allocate that memory will try everything, including compacting the heap,
in order to fullfill the request.  Since this might result in moving
blocks of memory, you lock the handle you want to work with, call the
routine (which, in the course of working with your handle, might move
memory, including the block your handle is referencing), then unlock the
handle.

You can, of course, leave handles locked across calls to WaitNextEvent
(the call that yields the cpu to the OS), but, like you point out, some
other program is likely to call a ToolBox routine that will move memory
and having a handle locked unnecessarily might prevent the OS from
allocating memory that some other program needs, which will result in an
'out of memory' error.

>OS may want to do garbage collection.  What does the OS do when it's
>garbage time, but many of the fragmented blocks are locked in place?  It
>can't move them, can it now? It can do a half-assed job, at best.
>
>I think that only a goof would implement memory management that forces
>an extra level of indirection on the application programmer via the use
>of handles.
>
>We are starting to uncover that the cooperative model of the Macintosh
>isn't quite as rosy as sprinkling "yield()" operations throughout your
>code (which is bad enough).  The advocacy cheeseheads neglected to
>mention that you may also have to lock down handles of memory blocks,
>and dereference pointers to the global heap with double indirection.
>
>What do I do if I want an optimized loop that references data in the global
>heap? I load the pointers into registers and work with them, right? But now
>I have to take care to yield at the right place. That means that what
>was going to be optimized code now has now to be split into more basic
>blocks. Furthermore, the address stored in the address register can become
>meaningless and will have to be re-loaded, unless the block it points
>to was locked. I have introduced an extra conditional into the code, plus
>a wasteful function call and other "wrapper" instructions, not to mention
>some variables that are used to compute when a yield should occur.

You only have to lock handles when your app calls certain ToolBox
routines, which are known to move memory (I believe these are marked as
such in Inside Macintosh.)  Since the MacOS currently uses cooperative
multitasking, you know precisely where in your code the yield will occur. 
You should always lock handles before using them, just as good coding
practice.  You don't have to leave them locked when you yield the CPU,
unless you yield in the middle of a loop which dereferences the handle.  I
would suggest that if you have a loop that takes long enough to execute
that you have to yield in the middle of it that you should probably unroll
the loop or redesign it somehow.

+--------------------------------------------------------------------+
|    wade@macc.wisc.edu                    WEMasshardt@eworld.com    |
+--------------------------------------------------------------------+
|               "Guns don't kill people, Phfor do."                  |
|                             - Marathon T-shirt                     |
+--------------------------------------------------------------------+