"Steve Holden" <[EMAIL PROTECTED]> wrote: > Hendrik van Rooyen wrote: > > "Fredrik Lundh" <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
