Rules governing stack purging
Mark Smith
mark at maseurope.net
Mon Oct 30 13:38:27 EST 2006
My experience is that having accessed a stack on disk, it remains in
memory until you explicitly close it ie. < close stack "/Users/
blah...." >
For some reason, when you've accessed the stack, but not yet closed
it, it doesn't show up in the openStacks, but does show up in the
application browser - once you've closed it, however, it seems to be
really gone from memory.
Perhaps not showing up in the openStacks is a bug?
This is on Mac OS X, 2.7.4 (though I encountered this in 2.6xx, as
well).
Best,
Mark
On 30 Oct 2006, at 17:48, Richard Gaskin wrote:
>
> I'm working with a client on a system that makes extensive use of
> data stored in custom properties.
>
> I had been under the impression that as long as the stack
> containing the data has its destroyStack set to true, and as long
> as we don't open the stack, everytime we access its properties
> we're getting it fresh from disk rather than from cached memory.
>
> Is that correct?
>
> We're in the process of pinning down some anomalies in our system
> which would seem to suggest that accessing properties can cause a
> stack to remain in memory such that subsequent accesses are
> obtained from memory rather than from disk.
>
> I would love to be wrong, as it would complicate our system to have
> to manually purge each stack before accessing it.
>
> And as for that purging, in the absence of a purge command there is
> the workaround of using the delete command, but at the moment my
> memory's flakey: does using "delete stack" merely purge the stack
> but not delete the actual stack if it's a mainStack, or if it's a
> substack?
>
> And once we confirm which type of stack we can safely purge without
> deleting it using the "delete stack" command, what method do we use
> to purge stacks of the other kind?
>
> --
> Richard Gaskin
> Fourth World Media Corporation
> ___________________________________________________________
> Ambassador at FourthWorld.com http://www.FourthWorld.com
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
More information about the use-livecode
mailing list