On Tue, Feb 24, 2009 at 3:58 PM, Stefan Behnel <[email protected]> wrote: > 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).
I'm on your side here. I've just fixed my projects to generate the module cleanup function... > 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. > Well, I believe the module init+cleanup works pretty well, see this code: http://code.google.com/p/mpi4py/source/browse/trunk/demo/embedding/helloworld.c As the code is run between Py_Initialize()/Py_Finalize() pairs, in each step of the loop you have calls to the module init and cleanup functions. Of course, this requieres some care about how Python and C globals are initalized and managed. That's the reason you will see that I've pushed some fixes to explicit initialize to NULL some global stuff. >> >> 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. > Hey! Please read this thread... Even Guido seems to give-up on the issue ;-) http://mail.python.org/pipermail/python-dev/2009-February/086358.html >> 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. > OK, I'll need to learn how that type-copying works... > >> 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. > Mmm... not sure if it is rare in all cases... It is rare when you are wrapping libs, in other apps, perhaps it is not so rare... Again, see the thread in Python-Dev I've mentioned above. > > 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. > OK, let's go for it... but please, let's try hard to avoid reference cycles... -- Lisandro Dalcín --------------- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
