On Fri, 2004-02-27 at 18:05, Gustavo J. A. M. Carneiro wrote: > But the real issue is that Py_DECREF possibly triggers > g_object_unref(), and the latter is not (yet) thread-safe.
I think the sequence of events is: * a pygtk ListStore object gains a reference to a gtk ListStore * the gtk ListStore gains a reference to a python "Dummy" object * the pygtk ListStore becomes elligible for garbage collection * during garbage collection of the pygtk ListStore (in pygobject_clear) it requests that the gtk ListStore decrements its reference count (a call to g_object_unref). Before pygobject_clear calls g_object_unref it calls pyg_unblock_threads which releases the python interpreter lock. * the gtk Liststore references are now zero and in the course of its deallocation it asks each of the objects that it is managing to decrement their reference counts. * The callback to free the python "Dummy" object is the pygtk function pyobject_free, which doesn't try to reaquire the python interpreter lock before decrementing the Dummy object's reference count. The lack of the interpreter lock calls the intepreter to abort during deallocation of the Dummy object. > However, this patch is not a good idea at all, as it uses a couple of > very expensive mutex lock/unlock operations for each object freed. We > can avoid this, and following the gtk+ approach, if the programmer is > responsible for not sharing a single GObject between two threads. Or if > the programmer wishes to do so, he should use explicit locking around > operations on such objects. I'm not sure what your are suggesting here, the problem seems to be in the pygtk bindings of gtk, the python programmer is not in control of the interpreter lock. There aren't any threads in the example because I thought that would make it harder to follow and they're not needed to exhibit the problem, though the call to gtk.init_threads is needed to cause pygtk to attempt to acquire & free the interpreter lock. The operation might well be expensive but thats better than being erroneous ;) Its kinda weird though that new style python objects don't exhibit this problem, i would have thought that their deallocation would need the intepreter lock. cheers, Graham _______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
