[futurebasic] Re: When to dispose of Hndl& and Ptr&?

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : December 1997 : Group Archive : Group : All Groups

From: David Blache <microcsm@...>
Date: Sat, 6 Dec 97 12:14:14 -0600
morethanone wrote:

>That did it... the problem went away.  I guess the question is, is there
>some way to decide how often to lock/unlock? Every time you use the
>handle, because there's no way of knowing when a handle will need to
>"float"? Just when the code might change the size of the data?

It's not when you use the handle, but how that determines when you should 
lock it down.  First let me try to explain why failing to lock a handle 
under certain circumstances will cause you to crash...

A handle is a pointer to a master pointer.  Using this scenario, the 
Memory Manager can move the data pointed to by the master pointer at 
will, and update the master pointer to the new location, all without you 
being the slightest bit aware of it.  Freely floating blocks are good 
things.  ;-)  The danger comes in when you, the programmer, dereference 
that handle.  Let's say I have a handle called myHndl&.  And I am about 
to go into a loop looking at the contents of that handle:

myPtr = myHndl&
FOR offset& = 1 to FN GetHandleSize(myHndl&)
  myPtr& = myPtr + offset&
  char = {myPtr&}
NEXT offset&

This loop is fine and dandy as long as the handle doesn't move while the 
loop is executing.  If it were to move, the myPtr& variable would still 
be pointing to the OLD location, and in this case, I would be reading 
whatever was at that location.  Remember...the Memory Manager moves the 
block and then reassigns a new master pointer - but it would be asking a 
little much for it to update your variables.  Since the old location 
previously held the data I am looking at, the characters I am grabbing 
may look perfectly good - even though my data has moved.  This is because 
when the memory manager moves a block, it doesnt take the time to clear 
the old location in memory.  You'd be surprised how many calls we get 
from programmers swearing that there is a bug in FutureBASIC, when after 
investigation, we find it is this sort of thing that is causing the 
problem.  ;-)

|       David Blache - Developer       |
|   Staz Software, Inc - Stazologist   |
|        (tech@...)       |
|   Microcosm Software, Inc. - Owner   |
|        (microcsm@...)        |