Rules governing stack purging

Jerry Daniels jerry at daniels-mara.com
Tue Oct 31 10:16:58 EST 2006


Richard, et al.,

Any reference to any object in a stack (or the stack itself) that  
includes its file path name (the long name, the long id) will place  
it in memory. You might consider that. We had that bite us several  
times with Constellation and Galaxy in managing our tabs for objects.

Best,

Jerry Daniels

Makers of Galaxy 1.5
http://www.daniels-mara.com/new_in_galaxy_1_5.htm



On Oct 30, 2006, at 10:48 AM, 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