On Mon, Mar 01, 2004 at 03:34:00PM +0000, Graham Carlyle wrote:
> 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.
I agree, and it does sound like a bug to me. Gustavo seems to be
concerned about [unconditionally?] locking around the Py_DECREF() call,
which in this case suggests to me the best path is to open a bug report
in bugzilla.gnome.org. If you could include your testcase and analysis
above, it would be a great description for the bug, already.
For reference, the mailing list thread for the issue is at:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg07726.html
> > 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.
The issue is: what operation is Graham invoking that *could* be
protected by locking?
> 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.
This is the part that confuses me. I asked before: if you do
threads_init() at the beginning of the program (before creating the
ListStore) do things work as expected? What does threads_init() do that
makes Py_DECREF an operation that requires thread locking?
I wonder if a potential solution is to lock around the Py_DECREF()
*when* threading is enabled?
Take care,
--
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331
_______________________________________________
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
