Python/Tkinter crash.

[Hendrik van Rooyen]

"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.
> >>
> >></F>
> >
> >
> > I must be dense - After I have called mainloop, if I have not started
another
> > thread to respond to events that are not generated by the user on the screen
(in
> > this case values of variables to display from the field generated by
different
> > processes - there is other hardware out there), how do I get control back to
do
> > 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
I
> > don't unblock it, then the gui will grind to a halt....so I need a thread
for
> > the pipe between processes, and a queue between threads, and a time out
based
> > polling loop to read the queue, it seems - is it even safe to change a main
loop
> > 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
must
> > base that on a timed callback too, and somehow keep state between
callbacks...
> > now is it ok to call widget command methods from a callback in the same
thread,
> > or do I have to use invoke?
> >
> > My head is beginning to hurt... - what was a nice simple threaded
implementation
> > is turning into a spaghetti monster of timed callbacks - you thought gotos
was
> > bad? - you aint seen nothing yet...
> >
> See if this helps:
>
>      http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/82965
>
> 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
better...

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

Thank You All.
- Hendrik