On Sun, Jun 12, 2005 at 10:19:03PM -0400, John K Luebs wrote: > On Wed, Jun 08, 2005 at 01:53:37PM +0200, Antoon Pardon wrote: > > > > | John K. Luebs reminds you: *don't forget gtk.threads_enter() and > > | gtk.threads_leave()* around mainloop when accessing gtk code if you want > > | your application to actually work threaded: > > | > > | gtk.gdk.threads_enter() > > | gtk.main() > > | gtk.gdk.threads_leave() > > > > I think this is wrong although it doesn't seem to hurt. > > > > >From the reference pages I understand that gtk.gdk.threads_init > > initializes a lock and that gtk.gdk.threads_enter() acquires > > this lock while gtk.gdk.threads_leave() releases it. In any case > > it is all about marking critical sections. > > > > Now marking the gtk.main() as such a critical section would > > mean that all other threads wanting to enter a critical section > > with gtk.gdk calls would be stopped from doing so until gtk.main > > had quit. That seems less than usefull. > > > No, because if and when gtk_main sleeps or waits, it will drop the lock > at the proper time. This design keeps things consistent.
Well I differ about that. IMO there is nothing consistent about having a programmer mark a particular code as critical and then have the internals of that code reverse the decision. > Remember that > in a GTK signal callback the lock will of course be held Yes, a big wart IMO. I have a program where I have to start a signal callback with a gtk.gdk.leave() call because it would otherwise deadlock. -- Antoon Pardon _______________________________________________ pygtk mailing list [email protected] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
