Rules governing stack purging
ambassador at fourthworld.com
Tue Oct 31 13:27:07 CST 2006
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
> 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
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
> 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
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?
Fourth World Media Corporation
Ambassador at FourthWorld.com http://www.FourthWorld.com
More information about the use-livecode