Rules governing stack purging

[Richard Gaskin]

Dave Cragg wrote:

> On 30 Oct 2006, at 22:43, Richard Gaskin wrote:
> 
>> Consider your subsequent post:
>>
>>> I just remembered something (third time this week, must be the   
>>> new pills). Aren't "unused" stacks purged from memory by the  
>>> engine  when it needs to reclaim memory? I think I'm referring to  
>>> stacks  without the destryStack set, but which have been closed. I  
>>> seem to  recall reading this somewhere, either in the old Metacard  
>>> docs, or  the MC mailing list from long ago. If it's true, I  
>>> wonder if it  applies to "unopened" stacks in memory too.
>>
>> This implies the engine introduces a "sometimes" rule ("sometime it  
>> does one thing, sometimes something else"), which is generally bad  
>> news.
> 
> If this purging actually happens, which I don't know for sure, I  
> don't think it's such a bad thing. It would only affect stacks that  
> have been specifically closed, or that have been put in memory as a  
> result of a direct reference to the stack file. Any subsequent  
> reference just requires the engine to load the stack again. Nothing  
> lost.

But it's still ambiguous; you never really know whether the stack is 
coming fresh from disk or whether its the copy that was last in memory.

By honoring the destroyStack property consistently with its behavior for 
"go" and "open", we would gain greater certainty about what's in memory.


> I'm still don't see how your suggestion will produce something more  
> "consistent" than the current behavior. Going back to my set and save  
> example:
> 
>   set the cProp of stack "C:/myStack.rev" to tData
>   save stack "C:/myStack.rev"
> 
> Under your proposal, if the stack's destroyStack property is true,  
> nothing will have changed in the stack. I don't see how this can be  
> considered consistent with anything.

Under what circumstances do you want to save changes to a stack that you 
neither open nor have its destroyStack left in its default setting?


> You say you were caught by this, but I'm still not clear what  
> problems it causes. The only situation I can think of is if a second  
> app changed the stack on disk while the first app had it in memory,  
> and the first app expected subsequent references to load the stack  
> from disk again. If this is the case, I don't think it is a normal  
> situation, and we know we have to take care when two apps are mucking  
> around with files. 

Ever make multi-user apps?  I make quite a few.

I'm not sure what "normal" means in this context.  I think a lot of 
single-user apps are "abnormal". :)


> But under your suggestion, if I want to use a  
> stack as a data file, I have to be sure to set it's destroyStack to  
> false. I suspect more people will be caught by that.

Whether we honor destroyStack for property access or not, either 
circumstance will require the addition of a line of code to cover all bases.

If we leave the current situation where destroyStack is ignored for 
property accesses, we can work around this by adding a line using the 
"delete stack" command.

If we honor destroyStack for property accesses, you can work around this 
by adding a line to open the stack invisibly first, or solve it with no 
code at all by just leaving the destroyStack property in its default 
setting.


It may also be worth noting that while we have the "delete stack" 
workaround, it only applies to mainStacks.  Using the same command on 
the other type of stack, substacks, will cause the stack to be deleted 
from the file.

So not only do we have a dangerous ambiguity in the language (addressed 
in BZ#1081), we also have no way of purging substacks from memory directly.

Here's a circumstance in which I don't know what the result would be:

You have a stack file with mainstack "A" and substack "B", both with 
their destroyStack set to true.  You open substack "B", which causes the 
whole stackfile to be read into memory, but do not open stack "A".

When you close stack "B", does the stackfile remain in memory?

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com