On Sat, Jan 30, 2010 at 6:14 PM, Haïkel Guémar <karlthered(a)gmail.com> wrote:
Le 30/01/2010 18:05, Paulo Cavalcanti a écrit :
> It is not a pleasant situation when your code does not work because
> the programming language does not do what it is supposed to.
> I am not raising any kind of rant here. I am just pointing that there is
> a problem
> that could have been already solved.
The use case provided there is broken by design, multiple threads try
use the same Label object.
Until here, we agree. Whenever a tkinter object is accessed from
another thread, the program will abort (when tcl is not built with thread
Since Tkinter is currently *not* thread-safe, you shouldn't expect this
stuff working properly.
Surely, it will not be thread safe when tcl is not built with thread
Whether you compile tcl/tk with threads support doesn't matter,
problem *lies* in the python layer. It might work on your machine, but
it's guaranteed to work elsewhere.
Maybe it is not 100% safe
but I did not see a single example where it does not work when tcl is built
with thread enabled.
"Now what you can do when tcl/tk is compiled with --enable-threads and
python has thread support too is creating threads in python and
changing tk widgets in another thread. tkinter will schedule these
calls from other threads to run in the main thread (with a probability
I can not comment the "probability of fail". I would have to look at
Anyway, if you need a multithreaded Tkinter, then you'll have to build
mtTkinter which is not packaged for Fedora at that time.
mtTkinter just makes the program work either with tcl thread enabled or not.
It is a very small module (160 lines):
import mtTkinter as Tkinter
# Use "Tkinter." as usual.
from mtTkinter import *
# Use Tkinter module definitions as usual.
It also has a small test, which I am attaching a screen shot.
One can read:
mtTkinter works with or without Tcl thread support
Anyway, the discussion was good and maybe it is useful to other people too.
Paulo Roma Cavalcanti
LCG - UFRJ