On Fri, Jan 21, 2005 at 09:44:46AM -0500, Dave Aitel wrote: > Honestly, you save yourself days of debugging if you stick to a "GUI > thread" and have all real work done in other threads. This requires a > GUI Thread "queue" that you have it clean when it gets a chance. This is > how CANVAS works, and we work on anything from *BSD to Windows this way. :> > > Just my opinion, but if you find yourself doing a lot of > thread_enter()/thread_leave(), you're guaranteed to introduce thousands > of tiny annoying deadlocks. > > -dave >
Well it's not a matter of doing my self a favor but a matter of correct information and a matter of pygtk not making things more complicated as they should. 1) The correct information part is because I'm thinking about writing a tutorial on using threads with pygtk. 2) I think gui-programs with threading are already complicated enought, without the librarry introducing extra complications. So I ask for the possibility that signal handlers wouldn't be embedded in a gtk.threads_enter and get.threads_leave pair My arguments are as follows. There are two possibilities if you use threading with pygtk. Either you arrange your code that gtk.gdk call is done from the main thread or you don't. In the first case the embedding does no harm but is unneeded. In the second case the embedding may be a safe guard in simple examples but in general is a nuissance. For examples it complicates code if you have functions that can be called from the gtk as well as from other threads. In my first attempt to write a threaded program I ended up doing a gtk.threads_leave() call as my first statement in the On_Delete signal handler because otherwise the program would blok when I wanted to end it. So in the end embedding signal handlers between a gtk.threads_enter and get.threads_leave pair in general make things more difficult instead of making them easier so I think programmers should have at least the possibility to turn it off. -- 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/