On 6/16/05, Antoon Pardon <[EMAIL PROTECTED]> wrote: > 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. This is a common idiom. Conditions and signals come to mind. You acquire a lock and then wait on a condition. The condition unlocks the lock. When another thread signals the condition, the waiting thread is woken up owning the lock.
Think of event handlers as being in the context of main, but when main is not doing anything it does not make any sense to continue to hold the lock, which would prevent you from doing anything in another thread. > > > 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 pygtk@daa.com.au > http://www.daa.com.au/mailman/listinfo/pygtk > Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/ > -- Christopher Lambacher [EMAIL PROTECTED] _______________________________________________ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
