Adam Olsen added the comment: > Adam, did you notice the change on revision 59231 ? the > PyGILState_Ensure stuff should now remain valid during the > PyInterpreterState_Clear() call.
That doesn't matter. PyGILState_Ensure needs to remain valid *forever*. Only once the process is completely gone can we be sure it won't be called. Note that PyGILState_Ensure has two behaviours: it can be called when your thread is already running python code and has a tstate, or it can be called when you have none. revision 59231 fixed the former, but only when Py_Finalize hasn't finished. It doesn't fix it for any daemon threads, or for dummy threads (created outside of python's control). ... You're right, I did forget the 3 other places that acquire the interpreter_lock. The more I think about it the more I think our two approaches are equivalent, but conditionalizing the release means we don't need to touch the broken PyThread_exit_thread functions. I think the banning should be as early as possible, right after call_sys_exitfunc() has finished. You can't do anything sane once the interpreter is half-gone (despite the precedent of trying anyway.) __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1856> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
