[pygtk] gtk threading tutorial.

Antoon Pardon Antoon.Pardon at rece.vub.ac.be
Mon Oct 31 16:37:25 WST 2005

On Thu, Oct 27, 2005 at 01:38:24PM +0100, Gustavo J. A. M. Carneiro wrote:
> Qui, 2005-10-27 às 14:06 +0200, Antoon Pardon escreveu:
> > I have written a small gtk threading tutorial with a number
> > of demo's and an (IMO) helpfull module. I don't fancy
> > myself to be a good writer, but I thought the demo's
> > would make up for that. Let me know what you think.
> > 
> > http://www.pardon-sleeuwaegen.be/antoon/python/page0.html
> > 
>   This is a great tutorial.  Nice work!
>   However, there is one detail should not be neglected.  People more
> knowledgeable than I regarding gtk/pygtk in win32 tell me that in win32
> only the "main thread" can ever do GUI stuff.

You are right, I should mention this somewhere.

> Even if you acquire the
> gdk lock from a non-main thread, in win32 you'll still get problems.
> So, the only real solution for portable programming is to use the
> idle_add technique.

No this is not the only solution, the tube (more specifically the
idletube module) should work on windows too. I also think the
bare idle_add technique is not a real general solution.

The problem with just wrapping any gtkcall(args ...) into 
idle_add(gtkcall, args, ...) are the following.

1) The documentation doesn't guarantee, that the functions will be
   called in the order they were registered.

2) There can be an arbitrary delay between registration and calls.
   Granted this is a possibility with the tubes too, but the tubes
   can block threads when the numbers of registered functions grow,
   limititing the delay. While the bare idle_add will happily
   add registerd functions letting the the delay grow and grow.
   My demo version that made use of this technique could take
   a five second delay when stopping a thread and that was the
   only thread running then.

3) When the number of functions registerd grows, the likelyhood
   of a crash grows. A freeze of the program with an error like
   Xlib: unexpected async reply (sequence 0xbca81)!, was very
   likely, when all seven threads ran.

Antoon Pardon

More information about the pygtk mailing list