[Edu-sig] re: Pygeo, platforms, wx and Tk

Douglas S. Blank dblank at brynmawr.edu
Wed Dec 15 18:15:56 CET 2004


We have multiple threads interacting with a Tk window (Pyro Robotics). 
But it has proven very reliable---even without any locks of any sort. I 
did make sure that we only have one Tk interpreter; it is easy to 
accidently create more than one.

One situation does fail relably, however: on machines that have multiple 
processors, it seems that the Tk update code often steps on itself. I 
have tried to come up with a stripped-down example of the failure, but 
alas have not been able to pinpoint the problem.

-Doug

John Zelle wrote:
> Arthur,
> 
> In our VR work here, we do something very similar to what you are doing, 
> but in an impoverished way. We use a Tk panel to control simulations in 
> VPython. We have done this using threads and run on both Linux (our 
> primary platform) and Windows with no hitch. The main difference, I 
> think, is that we are not trying to communicate back from VPython to the 
> Tk panel. We can spin and zoom in the Vpython window, and control other 
> parameters through Tk. I guess I don't see any reason in principle that 
> the two-way communication shouldn't work.
> 
> I suspect, can't tell without digging into your code, that the problem 
> is that you end up making Tk calls from two different threads. That is 
> strictly a no-no. It used to be the case that Tk calls could only be 
> made in the thread that did the Tkinter import. I think that it's now OK 
> to import, but only make calls in the thread the creates the main app 
> (calls Tk() to get the root widget).
> 
> If you are not currently doing this, the next step to try is to create 
> the Tk interface in main program, and have that initial program call the 
> Tk mainloop. That means that the VPython stuff will actually be created 
> and run in the separate thread. As long as mainloop() is in your initial 
> thread (the one that imports Tkinter and grabs Tk()), I think that your 
> approach will work under Linux and Windows.
> 
> If I get a little free time (hah!, it's finals week) I might try putting 
> together a little demo to see that this two-way communication works. By 
> the way, I hope you are using locks to protect any shared data across 
> the two threads.
> 
> --John
> 
> Arthur wrote:
> 
>> Kent writes -  
>>
>>> Thanks for the explanation. I didn't realize that the two panels are 
>>> using
>>> different GUI frameworks.
>>> I don't know how to make that work...
>>>
>>> Kent
>>>   
>>
>>
>> Well, that's 2 of us anyway ;)
>>
>> I'm suspecting that I will have more flexibility when VPython moves from
>> GTK1 to GTK2.  But that might too, be wrong.
>>
>> FWIW, Arnd had recently mentioned coming to a solution that included the
>> ipython interactive shell, when Idle could not serve his needs - 
>> because of
>> its use of sockets.
>>
>> It turns out I can't use ipython to serve my needs with VPython, 
>> because it
>> suffers from the same disease as did the old Idle - and which Idle solved
>> with the use of sockets. It closes when I close a VPython display
>>
>> Life sucks ;)
>>
>> Art
>>
>>
>> _______________________________________________
>> Edu-sig mailing list
>> Edu-sig at python.org
>> http://mail.python.org/mailman/listinfo/edu-sig
>>
>>
>>  
>>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
> 
> 


-- 
Douglas S. Blank,         Assistant Professor
dblank at brynmawr.edu,            (610)526-6501
Bryn Mawr College,   Computer Science Program
101 North Merion Ave,       Park Science Bld.
Bryn Mawr, PA 19010  dangermouse.brynmawr.edu


More information about the Edu-sig mailing list