On 11/29/2010 12:12 AM, Kristján Valur Jónsson wrote:
Some months back I mentioned that I had other stuff in store for GC.
Here is an idea for you. This particular idea is just a generalization of a system we’ve used in EVE for years now: garbage collection callbacks.
The need, originally, was to be able to quantify the time spent in garbage collection runs. Since they occur out of direct control of the application, we needed to have python tell us about it somehow.
We added gc.register_callback(), a function that added a callable to an internal list of functions that get called on two occations:
1)When a garbage collection run Is about to start
2)When a garbage collection run has finished.
The cases are distinguished using an integer argument. The callbacks are invoked from gc with gc inhibited from reentry, so that the callbacks cannot themselves cause another gc run to commence.
What we traditionally use this for is to start and stop a performance timer and other stats.
More recently though, we have found another very important use for this. When gc finds uncollectable objects, they are put in the gc.garbage list. This then needs to be handled by the application. However, there is no particularly good way for the application to do this, except to periodically check this list.
With the above callback, modules that create uncollectable objects, such as classes with __del__ methods, can register their callback. At the end of a gc run, they can then walk gc.garbage and take appropriate action for those objects it recognizes.
So, what do you think? This is a very simple addition to gc, orthogonal to everything and easily implemented. I also think it is very useful.
I presume the slowdown in the normal case consists of a very quick 'if callback list is not empty' check. If others agree and you open an issue with a ready-to-go patch (code, doc, test, what's-new), getting in 3.2b1 might be possible.