Hendrik van Rooyen
mail at microcorp.co.za
Fri Oct 6 07:33:30 CEST 2006
"Steve Holden" <steve at holdenweb.com> wrote:
> Hendrik van Rooyen wrote:
> > "Fredrik Lundh" <fredrik at pythonware.com> 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.
> > 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 halt....so 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?
> > 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.
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
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.
More information about the Python-list