Hi, Lisandro Dalcin wrote: > On Tue, Feb 24, 2009 at 11:36 AM, Stefan Behnel wrote: >> This would be a Py3-only feature. The cleanup code for Py2 would still be >> optional. > > However, some people could argue that cleanup code will slow-down > Python process termination.
We are much too early in the design process to think about this kind of performance issues. We can always make it optional in Py3, too, but on by default (if it works out well, that is). Being able to cleanly unload and reload C modules is a plain great feature that's very valuable in it's own right. Honestly, the cleanup code is mostly there, it just needs to be adapted to the normal GC interface. >>> A concrete example might help explain things. Say I have a Cython class >>> >>> class A: >>> def __del__(self): >>> print 1 >>> >>> Now when this is compiled, a python int 1 will be created and stored >>> in the module dictionary. If the module defining A is cleaned up >>> before every instance of A is deallocated, then the cached Python 1 >>> will be collected and then at some later point A.__del__ could be >>> called, which may result in a segfault. >> Ok, but all this means is that the class needs to hold a reference to the >> module instance that created it, right? > > That would work, but such approach will introduce reference cycles > that I would like to avoid. 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. > And of course, you need a extra slot in > object struct of cdef classes... But that's plain cheap. It just means that each type will be copied on the heap in the module init function (there's a simple helper function for that), and then receive a reference to the module instance. So it's one copy of the type per copy of the module. And we could even decide if we really need to make a copy of the type, based on its declaration. > 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. > For > example, in petsc4py and slepc4py (the second depend on the first, and > the second cimport types from the first) I'm able to generate > full-cleanup code for both. But this work as long as cimported types > are not nullified (I've just pushed a fix for this, I made a mistake > in a previous commit), and just because core CPython does not > dlclose() extension modules and extension types are not heap-types > (i.e. the typeobject struct is always available on static storage). I didn't say it would be trivial. I'm just saying that this is a valuable goal. And Cython is definitely the right tool to achieve it. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
