It seems as if garbage collection within a python thread of a pygtk object that itself has a reference to a python object will cause the interpeter to abort.
This is because the pygtk code that is called when gtk calls back to remove the object referenced by the gtk object, that is itself being removed, doesn't properly restore the current python thread state.
Is the pygtk code trying to switch to a new thread state and not switching back? I think the problem is that pygtk has no knowledge of the thread that the gc is running on. One possible solution is to queue objects for actual deref'ing on the main thread.
I'm not sure what the best solution is because I'm not clear why the pygtk code is trying to avoid the PyGILState APIs.
The PyGILState api's were buggy and could easily deadlock in python 2.3.4 and before.
John _______________________________________________ pygtk mailing list [email protected] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
