Author kristjan.jonsson
Recipients kristjan.jonsson, pitrou, tim.peters
Date 2010-07-02.13:59:10
SpamBayes Score 0.000134377
Marked as misclassified No
Message-id <1278079153.27.0.59964514373.issue9141@psf.upfronthosting.co.za>
In-reply-to
Content
1. The use case is any C extension that may need to run non-trivial code when being deleted, but where this can not be statically known.  An example in the code today is generators, and the PyGen_NeedsFinalizing() function, doing exactly this.  This is an attempt to make this functionality available to any C extension.

2. No, this gives a C extension the oppertunity to say: It's okay to delete me from GC, or it's not okay to delete me from GC.  There is no need to specify any particular finalizing function, it will be invoked when the refcount goes to 0, just as it happens with __del__(), or as it happens with PyGen objects.

3. This code is only invoked for garbage deemed collectable.  As such it is not on any critical path, most gc collections don't actually find any garbage. The cost of a few extra indirect function calls is likely to drown in the memory allocator overhead when the objects are released. 

Also, this is designed to be a minimum impact patch.  We really shouldn't be creating new slot methods when it can be avoided.
History
Date User Action Args
2010-07-02 13:59:13kristjan.jonssonsetrecipients: + kristjan.jonsson, tim.peters, pitrou
2010-07-02 13:59:13kristjan.jonssonsetmessageid: <1278079153.27.0.59964514373.issue9141@psf.upfronthosting.co.za>
2010-07-02 13:59:11kristjan.jonssonlinkissue9141 messages
2010-07-02 13:59:10kristjan.jonssoncreate