Programming Python (86 page)

Example 10-26. PP4E\Gui\Tools\pipe-gui1.py

# GUI reader side: route spawned program standard output to a GUI window
from PP4E.Gui.Tools.guiStreams import redirectedGuiShellCmd       # uses GuiOutput
redirectedGuiShellCmd('python -u pipe-nongui.py')                 # -u: unbuffered

Example 10-27. PP4E\Gui\Tools\pipe-nongui.py

# non-GUI side: proceed normally, no need for special code
import time
while True:                          # non-GUI code
print(time.asctime())            # sends to GUI process
time.sleep(2.0)                  # no need to flush here

Figure 10-15. Messages printed to a GUI from a non-GUI program (command
pipe)

Example 10-28. PP4E\Gui\Tools\pipe-gui2.py

# GUI reader side: like pipes-gui1, but make root window and mainloop explicit
from tkinter import *
from PP4E.Gui.Tools.guiStreams import redirectedGuiShellCmd
def launch():
redirectedGuiShellCmd('python -u pipe-nongui.py')
window = Tk()
Button(window, text='GO!', command=launch).pack()
window.mainloop()

Either way we code them, however, when the GUIs of
Example 10-26
and
Example 10-28
are run they
become unresponsive for two seconds at a time while they read data
from the
os.popen
pipe. In fact,
they are just plain sluggish—window moves, resizes, redraws, raises,
and so on, are delayed for up to two seconds, until the non-GUI
program sends data to the GUI to make the pipe read call return.
Perhaps worse, if you press the “GO!” button twice in the second
version of the GUI, only one window updates itself every two seconds,
because the GUI is stuck in the second button press callback—it never
exits the loop that reads from the pipe until the spawned non-GUI
program exits. Exits are not necessarily graceful either (you get
multiple error messages in the terminal window).

Because of such constraints, to avoid blocked states, a
separately running GUI cannot generally read data directly if its
appearance may be delayed. For instance, in the socket-based scripts
of the prior section (
Example 10-25
), the
after
timer loop allows the GUI to
poll
for data instead of
waiting
, and display it as it arrives. Because it
doesn’t wait for the data to show up, its GUI remains active in
between outputs.

Of course, the real issue here is that the read/write loop in
the
guiStreams
utility function
used is too simplistic; issuing a read call within a GUI is generally
prone to blocking. There are a variety of ways we might try to avoid
this.

One candidate fix is to
try to run the redirection loop call in a thread—for
example, by changing the
launch
function in
Example 10-28
as follows (this is from file
pipe-gui2-thread.py
on the examples
distribution):

def launch():
import _thread
_thread.start_new_thread(redirectedGuiShellCmd, ('python -u pipe-nongui.py',))

But then we would be updating the GUI from a spawned thread,
which, as we’ve learned, is a generally bad idea. Parallel updates can
wreak havoc in GUIs.

If fact, with this change the GUI fails
spectacularly
—it hangs immediately on the first
“GO!” button press on my Windows 7 laptop, becomes unresponsive, and
must be forcibly closed. This happens before (or perhaps during) the
creation of the new pop-up scrolled-text window. When this example was
run on Windows XP for the prior edition of this book, it also hung on
the first “GO!” press occasionally and always hung eventually if you
pressed the button enough times; the process had to be forcibly
killed. Direct GUI updates in threads are not a viable
solution.

Alternatively, we could try to use the Python
select.select
call (described in
Chapter 12
) to implement polling for data on the
input pipe; unfortunately,
select
works only on sockets in Windows today (it also works on pipes and
other file descriptors in Unix).

In other contexts, a separately spawned GUI might also use
signals to inform the non-GUI program when points of interaction
arise, and vice versa (the Python
signal
module and
os.kill
call were introduced in
Chapter 5
). The downside with this approach
is that it still requires changes to the non-GUI program to handle the
signals.

Named pipes (the fifo files introduced in
Chapter 5
) are sometimes an alternative to
the socket calls of the original Examples
10-23
through
10-25
, but sockets work on standard
Windows Python, and fifos do not (
os.mkfifo
is not available in Windows in
Python 3.1, though it is in Cygwin Python). Even where they do work,
we would still need an
after
timer
loop in the GUI to avoid blocking.

We might also use tkinter’s
createfilehandler
to register a callback to
be run when input shows up on the input pipe:

def callback(file, mask):
...read from file here...
import _tkinter, tkinter
_tkinter.createfilehandler(file, tkinter.READABLE, callback)

The file handler creation call is also available within
tkinter
and as a method of a
Tk
instance object. Unfortunately again, as
noted near the end of
Chapter 9
,
this call is not available on Windows and is a Unix-only
alternative.

As a far more general solution to the blocking input delays of
the prior section, the GUI process might instead spawn a thread that
reads the socket or pipe and places the data on a queue. In fact, the
thread techniques we met earlier in this chapter could be used
directly in such a role. This way, the GUI is not blocked while the
thread waits for data to show up, and the thread does not attempt to
update the GUI itself. Moreover, more than one data stream or
long-running activity can overlap in time.

Example 10-29
shows
how. The main trick this script employs is to split up the input and
output parts of the original
redirectedGuiShellCmd
of the
guiStreams
module we met earlier in
Example 10-12
. By so doing, the
input portion can be spawned off in a parallel thread and not block
the GUI. The main GUI thread uses an
after
timer loop as usual, to watch for data
to be added by the reader thread to a shared queue. Because the main
thread doesn’t read program output itself, it does not get stuck in
wait states.

"""
read command pipe in a thread and place output on a queue checked in timer loop;
allows script to display program's output without being blocked between its outputs;
spawned programs need not connect or flush, but this approaches complexity of sockets
"""
import _thread as thread, queue, os
from tkinter import Tk
from PP4E.Gui.Tools.guiStreams import GuiOutput
stdoutQueue = queue.Queue()                        # infinite size
def producer(input):
while True:
line = input.readline()                    # OK to block: child thread
stdoutQueue.put(line)                      # empty at end-of-file
if not line: break
def consumer(output, root, term=''):
try:
line = stdoutQueue.get(block=False)        # main thread: check queue
except queue.Empty:                            # 4 times/sec, OK if empty
pass
else:
if not line:                               # stop loop at end-of-file
output.write(term)                     # else display next line
return
output.write(line)
root.after(250, lambda: consumer(output, root, term))
def redirectedGuiShellCmd(command, root):
input  = os.popen(command, 'r')                # start non-GUI program
output = GuiOutput(root)
thread.start_new_thread(producer, (input,))    # start reader thread
consumer(output, root)
if __name__ == '__main__':
win = Tk()
redirectedGuiShellCmd('python -u pipe-nongui.py', win)
win.mainloop()

As usual, we use a queue here to avoid updating the GUI except
in the main thread. Note that we didn’t need a thread or queue in the
prior section’s socket example, just because we’re able to poll a
socket to see whether it has data without blocking; an
after
timer loop was enough. For a
shell-command pipe, though, a thread is an easy way to avoid
blocking.

When run, this program’s self-test code creates a
ScrolledText
window that displays the
current date and time sent from the
pipes-nongui.py
script in
Example 10-27
. In fact, its
window is identical to that of the prior versions (see
Figure 10-15
). The window is
updated with a new line every two seconds because that’s how often the
spawned
pipes-nongui
script prints
a message to
stdout
.

Note how the producer thread calls
readline()
to load just one line at a time.
We can’t use input calls that consume the entire stream all at once
(e.g.,
read()
,
readlines()
), because such calls would not
return until the program exits and sends end-of-file. The
read(N)
call would work to grab one piece of
the output as well, but we assume that the output stream is text here.
Also notice that the
-u
unbuffered
stream flag is used here again, to get output as it is produced;
without it, output won’t show up in the GUI at all because it is
buffered in the spawned program (try it yourself).