Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #35300 > unrolled thread

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

Back to article view | Back to comp.lang.python

Contents

  Second try: non-blocking subprocess pipe and Tkinter in 2.7 Kevin Walzer <kw@codebykevin.com> - 2012-12-21 10:52 -0500
    Re: Second try: non-blocking subprocess pipe and Tkinter in 2.7 Peter Otten <__peter__@web.de> - 2012-12-21 17:33 +0100
    Re: Second try: non-blocking subprocess pipe and Tkinter in 2.7 Terry Reedy <tjreedy@udel.edu> - 2012-12-21 22:00 -0500

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

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
-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

[toc] | [next] | [standalone]

#35305

Kevin Walzer wrote:

> 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

[toc] | [prev] | [next] | [standalone]

#35334

On 12/21/2012 10:52 AM, Kevin Walzer wrote:
> 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.

-- 
Terry Jan Reedy

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web