Author kristjan.jonsson
Recipients kristjan.jonsson, pitrou, stutzbach, tim.peters
Date 2010-07-09.22:48:30
SpamBayes Score 0.194099
Marked as misclassified No
Message-id <1278715713.41.0.647823933206.issue9141@psf.upfronthosting.co.za>
In-reply-to
Content
Hi Daniel.
Your message was classified as spam, I have no idea why, but this is why I only noticed it now.

Your suggestion is interesting, I hadn't thought of that.  Yes, it is possible to use the track/untrack functions (I think), but that would mean that you would have to monitor your object for every state change and reliably detect the transition from one state to another.  Being able to query the current state and let gc know:  "No, I cannot be collected as I am now" is a much more robust solution from the programmers perspective.

A further difference is this:  If an object isn't tracked, it won't be collected if it is part of a cycle, but it will not be put in gc.garbage either.  In effect, it will just remain in memory, unreachable, with no chance of it ever being released.

In contrast, a generator (or in my case, a tasklet) that needs to have a finalizer run when it goes away, will end up in gc.garbage, which a dilligent application will visit once in a while in order to clean it out.  I'm not sure how you would clear out a generator like that, but in Stackless python, you could do something like this once in a while:
for g in gc.garbage:
  if isinstance(g, stackless.tasklet):
    g.kill()
del gc.garbage[:]
History
Date User Action Args
2010-07-09 22:48:33kristjan.jonssonsetrecipients: + kristjan.jonsson, tim.peters, pitrou, stutzbach
2010-07-09 22:48:33kristjan.jonssonsetmessageid: <1278715713.41.0.647823933206.issue9141@psf.upfronthosting.co.za>
2010-07-09 22:48:32kristjan.jonssonlinkissue9141 messages
2010-07-09 22:48:30kristjan.jonssoncreate