Keith, On 2/21/08 2:31 AM, "Keith Peters" <[EMAIL PROTECTED]> wrote:
> It's probably too late for me to be trying to make sense of this, but Heh. If I'm not too tired to even make sense of what I think makes sense (parse THAT, Peters!), this is the key issue for me. I am completely clear on everything in this post (including the GC unpredictability and the system timer ref, in my prior email), but couldn't understand how, if the timer itself still existed, it could be collected--until I read this: "Here, the timer is a local variable..." Ha! I completely missed that. What a waste of bandwidth. While my example was intentionally different, my question about requiring that the timer be nullified is probably moot (as you also suggest) because it's local. (Me: Eyes being held open with toothpicks...) I'll think about this again when I have a clearer head. For instance, in the original example, only 10 iterations of the timer were specified. I would assume that this usage stops the timer after the tenth trigger, even without calling the stop() method (meaning a running timer is not the issue). Rich > yes, a weakly-referenced listener for most objects will be garbage > collected eventually, as long as no other reference remain. Here, the > timer is a local variable, and has a weak reference, so one might > think, hey, there is no more reference, it should be cleaned up. Of > course, WHEN, it would be cleaned up is anybody's guess. But, as I > illustrated in this post: > > http://www.bit-101.com/blog/?p=1169 > > it's NEVER going to get cleaned up. The system itself retains a ref to > the timer as long as it's running. This is different than a sprite or > mc running an enterFrame handler, which will eventually get cleaned up > if there are no refs to it. _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
