Stack Switching Question

Richard Gaskin ambassador at fourthworld.com
Wed Oct 5 23:19:01 EDT 2005


J. Landman Gay wrote:
> 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.

Of course but the stack is never truly open, so it's not about closing 
at all but about purging, something we don't have a token for.

> 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.

I'm on the fence on this one, esp. given that "delete stack" sometimes 
purges a stack and at other times actually deletes a stack.

If we had a "purge stack" command I'd happily go along with leaving 
control in the hands of the developer.

Maybe we could add "purge stack" at the same time as we rename the 
unnecessarily alarming "destroyStack" property to something more closely 
related to what it does. :)

--
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com



More information about the use-livecode mailing list