Callback to python function from Tkinter Tcl crashes in windows

Solution 1:

Each Tcl interpreter object (i.e., the context that knows how to run a Tcl procedure) can only be safely used from the OS thread that creates it. This is because Tcl doesn't use a global interpreter lock like Python, and instead makes extensive use of thread-specific data to reduce the number of locks required internally. (Well-written Tcl code can take advantage of this to scale up very large on suitable hardware.)

Because of this, you must make sure that you only ever run Tcl commands or Tkinter operations from a single thread; that's typically the main thread, but I'm not sure if that's the real requirement for integrating with Python. You can launch worker threads if you want, but they'll be unable to use Tcl or Tkinter (well, not without very special precautions which are more trouble than it's likely worth). Instead, they need to send messages to the main thread for it to handle the interaction with the GUI; there are many different ways to do that.

Solution 2:

I hesitate to contradict Donal and AFAICT he's correct with respect to Tcl, however the situation in cPython is, as the source code admits, more complicated. In short, cPython creates an extra lock around the Tcl interpreter and manages the call method to do as Donal suggests, sending a message to have the main thread call the desired command.

Because much of the Tk() methods are implemented in terms of call, this means a large footprint of the tkinter API is thread-safe (but not everything). Of particular interest is the after method which queues up work in the event loop without blocking the current thread for long.

Finally, I'd like to point out that the eval method seems to be thread-unsafe, as it simply sends a string to the Tcl interpreter for evaluation from whichever thread it's in.