Python/Tkinter crash.

Hendrik van Rooyen mail at
Fri Oct 6 07:33:30 CEST 2006

"Steve Holden" <steve at> wrote:
> Hendrik van Rooyen wrote:
> > "Fredrik Lundh" <fredrik at> wrote:
> >
> >>Eric Brunel wrote:
> >>
> >>
> >>>AFAIK, Tkinter is not thread safe. Using some kind of lock to serialize
> >>>the calls from different threads may seem to work (I never tested it
> >>>actually), but the safest way I found to use threads with Tkinter was to
> >>>call it only from the thread where the main loop executes.
> >>
> >>the Tkinter binding contains some code that attempts to deal with re-
> >>entrant calls, but I don't know/remember to what extent it's actually
> >>supposed to work (in other words, if the observed problems are bugs or
> >>just limitations).
> >>
> >>(maybe Martin's memory is better?)
> >>
> >>anyway, I usually play it safe and make sure to use a single thread to
> >>deal with the UI.
> >>
> >></F>
> >
> >
> > I must be dense - After I have called mainloop, if I have not started
> > thread to respond to events that are not generated by the user on the screen
> > this case values of variables to display from the field generated by
> > processes - there is other hardware out there), how do I get control back to
> > the necessary updating? - I suppose I can use the call back after some time
> > thingy to implement a polling loop - possibly as Russel Owen suggested - by
> > polling a queue - but queues are for between threads - and I have seen here
> > somewhere that sockets also want to be the main thread  - so that leaves a
> > pipe - and I have had bad experiences with pipes that are unblocked, and if
> > don't unblock it, then the gui will grind to a I need a thread
> > the pipe between processes, and a queue between threads, and a time out
> > polling loop to read the queue, it seems - is it even safe to change a main
> > variable from another thread? , or should I do it all via commands through a
> > queue, implementing a whole goddam serial protocol just between threads?
and If
> > I don't have another thread to do the timing for the animation bits, then I
> > base that on a timed callback too, and somehow keep state between
> > now is it ok to call widget command methods from a callback in the same
> > or do I have to use invoke?
> >
> > My head is beginning to hurt... - what was a nice simple threaded
> > is turning into a spaghetti monster of timed callbacks - you thought gotos
> > bad? - you aint seen nothing yet...
> >
> See if this helps:
> It's Jacob Hallen's description of how he solved the problem.
> regards
>   Steve

Thanks Steve - It is the same one Paul Rubin pointed me to and it describes
nicely how to get the "worker" thread going, and the queue between it and the
GUI thread.

In my case, I will have a thread for input, as well as one for output to send
commands away.  The bit I was complaining about above is the replacement of a
thread to do the animation timing with a "stutter" machine inside the gui
thread, where the timing is handled by callbacks.

A piece of feedback - the stutter machine animation timing is much smoother than
the timing based on threaded sleep calls.... - less jittery - looks much

So I am kind of glad the thing fell over because this implementation is going to
be much better.

Thank You All.
- Hendrik

More information about the Python-list mailing list