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/

Reply via email to