Second try: non-blocking subprocess pipe and Tkinter in 2.7

[Kevin Walzer]

Yesterday I posted a question about keeping a Tkinter GUI during a
long-running process, i.e. reading data from a pipe via the subprocess
module. I think that question did not quite get at the heart of the
issue because it assumed that Python, like Tcl which underlies Tkinter,
supports non-blocking, asynchronous reading out of the box. Apparently
it does not.

So, my question is hereby revised as such: how can I implement a
non-blocking read of a subprocess pipe that can write data to the
Tkinter text widget in an manner that does not cause the GUI to lock up?

--Kevin

 

[Peter Otten]

Yesterday I posted a question about keeping a Tkinter GUI during a
long-running process, i.e. reading data from a pipe via the subprocess
module. I think that question did not quite get at the heart of the
issue because it assumed that Python, like Tcl which underlies Tkinter,
supports non-blocking, asynchronous reading out of the box. Apparently
it does not.

So, my question is hereby revised as such: how can I implement a
non-blocking read of a subprocess pipe that can write data to the
Tkinter text widget in an manner that does not cause the GUI to lock up?

You could do blocking reads in a separate thread and use a queue to
communicate with the GUI in the main thread:

http://effbot.org/zone/tkinter-threads.htm

 

[Terry Reedy]

Yesterday I posted a question about keeping a Tkinter GUI during a
long-running process, i.e. reading data from a pipe via the subprocess
module. I think that question did not quite get at the heart of the
issue because it assumed that Python, like Tcl which underlies Tkinter,
supports non-blocking, asynchronous reading out of the box. Apparently
it does not.

There is currently the asyncore module, but I don't know that anyone
really likes it.

So, my question is hereby revised as such: how can I implement a
non-blocking read of a subprocess pipe that can write data to the
Tkinter text widget in an manner that does not cause the GUI to lock up?

Interesting question. Guido is currently, with help from many others
with async experience, working on a replacement for asyncore.
PEP 3156 - Asynchronous IO Support Rebooted
http://python.org/dev/peps/pep-3156/

You can read the pep if you want, but it includes a generalized event
loop interface. The prototype (partial) implementation includes (or
will) a default event loop. However, the intention is that it can be
replaced by (or maybe work with) adapters for existing event loops,
including that of gui frameworks. Being able write a tk loop adapter and
easily add io events and handlers to work along side with tk key and
mouse events and write to a widjet should be an interesting test of the
new framework.