On Fri, Feb 27, 2004 at 06:05:09PM +0000, Gustavo J. A. M. Carneiro wrote:
> A Sex, 2004-02-27 �s 13:22, Christian Robottom Reis escreveu:
> > On Mon, Feb 23, 2004 at 01:14:36PM +0000, Graham Carlyle wrote:
> > > --
> > > import pygtk
> > > pygtk.require("2.0")
> > > import gc
> > > import gobject
> > > import gtk
> > >
> > > class Foo:
> > > pass
> > >
> > > list_store = gtk.ListStore(gobject.TYPE_PYOBJECT)
> > > list_store.prepend((Foo(),))
> > > gtk.threads_init()
> > > list_store = None
> > > gc.collect()
> > > --
> > > results in the message:
> > > "Fatal Python error: PyThreadState_Get: no current thread
> > > Aborted"
> >
> > Isn't Py_DECREF supposed to be an atomic operation?
>
> Nope. This issue is not mentioned anywhere I could find. However,
> looking at source (see below), it doesn't look atomic to me...
Right, but thinking more about this, ISTM the real issue is that the
decref is being called in a different thread than the object was
created. So I'll ask again -- Graham, is there a reason for doing
threads_init() so late?
> 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.
Is this the case here? I don't know what threads_init() does, but I
wouldn't think it would cause the code above to run in separate threads;
however, the code above tells me it does *something*.
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/
