New submission from Graham Dumpleton <[EMAIL PROTECTED]>: In Python 3.0 the atexit module was translated from Python code to C code.
Prior to Python 3.0, because it was implemented at C code level, the list of callbacks was specific to each sub interpreter. In Python 3.0 that appears to no longer be the case, with the list of callbacks being maintained globally as static C variable across all interpreters. The end result is that if a sub interpreter registers an atexit callback, that callback will be called within the context of the main interpreter on call of Py_Finalize(), and not in context of the sub interpreter against which it was registered. Various problems could ensue from this depending on whether or not the sub interpreter had also since been destroyed. Still need to validate the above, but from visual inspection looks to be a problem. Issue found because mod_wsgi will trigger atexit callbacks for a sub interpreter when the sub interpreter is being destroyed. This is because Python prior to 3.0 only did it from the main interpreter. In Python 3.0, this all seems to get messed up now as no isolation between callbacks for each interpreter. For mod_wsgi case, since it is explicitly triggering atexit callbacks for sub interpreter, in doing so it is actually calling all registered atexit callbacks across all interpreters for each sub interpreter being destroyed. They then again get called for Py_Finalize(). Even if mod_wsgi weren't doing this, still a problem that Py_Finalize() calling atexit callbacks in context of main interpreter which were actually associated with sub interpreter. For mod_wsgi, will probably end up installing own 'atexit' module variant in sub interpreters to ensure separation. ---------- components: Interpreter Core messages: 75195 nosy: grahamd severity: normal status: open title: atexit module not safe in Python 3.0 with multiple interpreters type: behavior versions: Python 3.0 _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4200> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com