Stack Switching Question

[J. Landman Gay]

Dave Cragg wrote:
> 
> On 5 Oct 2005, at 21:04, Richard Gaskin wrote:
> 
>> J. Landman Gay wrote:
>>
>>> Richard Gaskin wrote:
>>>
>>>> I used the file name form to illustrate another difference  between 
>>>> HC and Rev:  while you would indeed need to open a stack  in HC in 
>>>> order to get stuff out of it, in Rev you can get  property values of 
>>>> objects in unopened stacks.  When you do that  the engine reads the 
>>>> file into memory to access what's being  requested; if the stack has 
>>>> been accessed before it'll stay in  memory (unless you turn on the 
>>>> stack's destroyStack property), so  subsequent accesses will be 
>>>> lightning fast.
>>>>
>>> Just an addendum: Actually, I've been using this technique on  
>>> multiple stacks, and found that once accessed, the stack stays  open 
>>> until you explicitly close it regardless of its destroystack  
>>> settings. I found this out after I accessed data from a ton of  
>>> external stacks and then discovered them all open later on. I had  to 
>>> specifically close them to remove them from RAM (their  destroystack 
>>> was true, so that did the trick.) If an accessed  stack has its 
>>> destroystack set to false, just closing it won't be  enough, the 
>>> script will have to delete it as well. (I know you  already know 
>>> that, Richard, just mentioning it for completeness.)
>>>
>>
>>
>> Actually I didn't know that. Is that a bug?  It rather invalidates  
>> the destroyStack property, no?
>>
> 
> I think we could debate that one for a month or two. :-)
> 
> I suppose the destroyStack is intended to apply when a stack is  closed, 
> and therefore has been explicitly opened earlier. Referencing  an 
> external stack isn't the same as opening it.

To me, it is like opening a stack invisibly without any system messages. 
At least, that's how I think of it. Destroystack applies to referenced 
stacks just as it does to stacked opened other ways -- when a script 
closes them, they are removed from memory if that property is set to 
true. Otherwise, a script must issue a "delete stack" command to get rid 
of it.

> 
> Like Jacque, I've been caught out with stacks in memory when I'd long  
> forgotten about. However, one practical problem for the engine to  
> overcome would be to determine when it should purge the stack.  
> Typically, when I reference an external stack, I'm likely to make a  few 
> references to it within a handler. Having to reload the stack for  each 
> reference could introduce an overhead. (Perhaps referenced  stacks 
> should be purged when any currently running handlers finish.)
> 
> Meanwhile, I try to remember to specifically delete each externally  
> referenced stack.

After some thought, I think the current implementation is correct. 
Destroystack doesn't (and shouldn't) control whether or not a stack 
closes, it just manages the stack's behavior when it does close.

In my situation, I sometimes need to refer to a stack repeatedly across 
handlers, and other times only need it once. I don't think I want the 
engine deciding for me when the stack should close, I'd rather control 
that myself. As long as I know that referencing a stack loads it into 
memory, closing it later at my convenience isn't a problem.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com