Python/Tkinter crash.

[Eric Brunel]

On Wed, 04 Oct 2006 20:02:56 +0200, Hendrik van Rooyen  
<mail at microcorp.co.za> wrote:
>  "Eric Brunel" <eric_brunel at despammed.com> wrote:
>> I know the problem happens sometimes on one of my Tkinter applications,
>> but I never succeeded in reproducing it systematically. I've browsed the
>> tcl bugs, but didn't find anything. Maybe you'll be luckier than I... If
>> you are, I'm interested in any hint you can find.
>
> Ouch! - this is a bit the wrong answer...

Sorry for that. I realize I wasn't very helpful, here...

> What I have seen, in mucking about today, is that it seems to be related  
> to
> threading - I have a silly sort of thread that runs, updating my meters,  
> more or
> less continuously, to simulate data from the field - it just adds some  
> values to
> the seven display variables and calls the update methods that delete and  
> redraw
> the arcs representing the analogue style meters, deleting and replacing  
> the text
> objects that show the values, and then it sleeps for a while, and does  
> it all
> again.
>
> At the same time, one other thread (other than the main thread), can be  
> created
> to move a component on the canvas around by calling its delete and draw
> methods. - but this is also done more or less continuously, as a new  
> thread is
> created as soon as the previous one dies to move the next object around.
>
> Now these two things are asynchronous with each other, so that given  
> enough
> time, they are bound to make calls to Tkinter in a re-entrant fashion,  
> and I
> suspect that it is this that is causing the problem - my "evidence" for  
> this is
> that I implemented a boolean as a sort of "lock" and had the Meter  
> updating back
> down in favour of the other animation to try and avoid any sort of re -  
> entrancy
> to the Tkinter canvas object's  delete and draw methods...

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 only thing  
that seems to work reliably in secondary threads is to generate custom  
events (widget.event_generate('<<MyCustomEvent>>', when='tail')), and to  
treat them in Tkinter's thread via bindings  
(widget.bind('<<MyCustomEvent>>', treatment_command)). This makes things a  
bit messy, but it works quite well.

Now, as I said before, someone reported that he *did* get the error you  
got from time to time. So maybe the problem I have is not the same as  
yours, or maybe there are some cases in my application where Tkinter stuff  
still gets called directly from secondary threads. I'll try to investigate  
that when I've time and I'll keep you informed.

HTH a little this time...
-- 
python -c "print ''.join([chr(154 - ord(c)) for c in  
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"