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.
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.
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. 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.
Cheers
Dave
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
