Why not event-driven packages in other than the main thread?

[Tor Erik]

Hi,

I've developed an application were I've used Tkinter for the GUI.
When I ran the GUI in another thread than the main, it kept locking
up.
I experienced similar problems with Twisted.

Both of these tools are event-based, so I guess that is the root of the
problem...

But could anyone tell me why running these in a thread other than the
main one doesn't work?

regards

 

[Bjoern Schliessmann]

But could anyone tell me why running these in a thread other than
the main one doesn't work?

Just for personal interest: Why would you want to run the GUI in
another thread? It's common to leave the GUI in the main thread and
let worker threads handle heavy time-consuming stuff.

Regards,


Björn

 

[Cliff Wells]

Hi,

I've developed an application were I've used Tkinter for the GUI.
When I ran the GUI in another thread than the main, it kept locking
up.
I experienced similar problems with Twisted.

Both of these tools are event-based, so I guess that is the root of the
problem...

But could anyone tell me why running these in a thread other than the
main one doesn't work?

They probably use signals (Twisted I'm sure does) and it's documented
that signals don't work with threads:

http://docs.python.org/lib/module-signal.html

Regards,
Cliff

--

 

[Cliff Wells]

They probably use signals (Twisted I'm sure does) and it's documented
that signals don't work with threads:

http://docs.python.org/lib/module-signal.html

Er, specifically, they only work with the main thread.

Cliff
--

 

[Lawrence Oluyede]

I've developed an application were I've used Tkinter for the GUI.
When I ran the GUI in another thread than the main, it kept locking
up.

That's because Tkinter is not thread safe AFAIK.

I experienced similar problems with Twisted.

Neither Twisted is thread-aware. It uses thread for a couple of things
(twisted.row and address resolution). You can call stuff in a separate
thread with deferToThread or callInThread but avoid threads is best.

But could anyone tell me why running these in a thread other than the
main one doesn't work?

Because neither Twisted nor Tkinter are meant to work with threads.

 

[Tor Erik]

Just for personal interest: Why would you want to run the GUI in
another thread? It's common to leave the GUI in the main thread and
let worker threads handle heavy time-consuming stuff.

Regards,


Björn

If you have two event-based frameworks, both needing to run in the main
thread, such as Tkinter and Twisted, you have a problem

 

[Lawrence Oluyede]

If you have two event-based frameworks, both needing to run in the main
thread, such as Tkinter and Twisted, you have a problem

Twisted supports Tkinter:
http://twistedmatrix.com/projects/core/documentation/howto/choosing-reac
tor.html#auto14

It's better to use GUI with a real reactor available like GTK2 anyway...

 

[Bjoern Schliessmann]

It's better to use GUI with a real reactor available like GTK2
anyway...

What's not real about Tkinter's?

Regards,


Björn

 

[Lawrence Oluyede]

What's not real about Tkinter's?

It's not a custom reactor as GTK's AFAIK

 

[Paul Rubin]

I've developed an application were I've used Tkinter for the GUI.
When I ran the GUI in another thread than the main, it kept locking
up. I experienced similar problems with Twisted.

Tkinter is not thread-safe. You have to synchronize any cross-thread
communication with it. The way I usually do it is with an "after"
method that checks a communications queue (Queue.Queue object) every
20 msec or so. Any communication to and from the gui thread is done
through the queue. There is a recipe like this in the Python Cookbook
and you can probably find it at ASPN.