On Feb 24, 2009, at 10:26 AM, Stefan Behnel wrote: > Hi, > > Dag Sverre Seljebotn wrote: >> Stefan Behnel wrote: >>> Hmm, true. When each object references its type, which in turn >>> references >>> the module instance, which in turn references the type, that >>> means that >>> *all* objects created in a module will end up requiring the GC >>> due to >>> reference cycles. >>> >>> I guess we need to raise these issues on python-dev. They'll be >>> happy to >>> dig into the real-life issues anyway. I'm pretty sure we'd be the >>> first to >>> actually use the new module features. >>> >>>> In any case, the only way to write safe code is to avoid the >>>> usage of >>>> module-level globals in __del__() and __dealloc__() methods... >>> Which is a rare thing anyway. Most of the time, you'd just call >>> some kind >>> of free() function and be done.
A more common case is that is uses an interned string (e.g. to lookup something in a dictionary). >> If it turns out these reference cycles will be a problem, I think we >> could always change Cython to *not* use initialized constants in >> __del__ >> and __dealloc__? (i.e. construct them on need; meaning a small >> performance penalty). Arbitrary code may be called from a __del__ and/or __dealloc__, how far would one go? Sometimes it's better to not special case just part of the problem. > Plus, we could generate an external closure for a type (not for the > instance, just the type object) that keeps all referenced global > values. > The type would then reference that instead of the module. > > I so like the idea of implementing these things under the hood, > instead of > requiring users to rewrite their code. I am solidly against adding another slot to cdef classes that reference their type/module, especially as it requires the class to be GC'd and creates cyclic references (which can have significant performance penalties in Python). Remember, this only happens right before the whole heap is deallocated, so the main use cases are to reduce noise during valgrinding and similar tools. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
