Programming Python (26 page)

Most computers
spend a lot of time doing nothing. If you start a system
monitor tool and watch the CPU utilization, you’ll see what I mean—it’s
rare to see one hit 100 percent, even when you are running multiple
programs.
^[
12
]
There are just too many delays built into software: disk
accesses, network traffic, database queries, waiting for users to click a
button, and so on. In fact, the majority of a modern CPU’s capacity is
often spent in an idle state; faster chips help speed up performance
demand peaks, but much of their power can go largely unused.

Early on in computing, programmers realized that they could tap into
such unused processing power by running more than one program at the same
time. By dividing the CPU’s attention among a set of tasks, its capacity
need not go to waste while any given task is waiting for an external event
to occur. The technique is usually called
parallel processing
(and sometimes
“multiprocessing”
or even “multitasking”) because many tasks seem to be
performed at once, overlapping and parallel in time. It’s at the heart of
modern operating systems, and it gave rise to the notion of
multiple-active-window computer interfaces we’ve all come to take for
granted. Even within a single program, dividing processing into tasks that
run in parallel can make the overall system faster, at least as measured
by the clock on your wall.

Just as important is that modern software systems are expected to be
responsive to users regardless of the amount of work they must perform
behind the scenes. It’s usually unacceptable for a program to stall while
busy carrying out a request. Consider an email-browser user interface, for
example; when asked to fetch email from a server, the program must
download text from a server over a network. If you have enough email or a
slow enough Internet link, that step alone can take minutes to finish. But
while the download task proceeds, the program as a whole shouldn’t
stall—it still must respond to screen redraws, mouse clicks, and so
on.

Parallel processing comes to the rescue here, too. By performing
such long-running tasks in parallel with the rest of the program, the
system at large can remain responsive no matter how busy some of its parts
may be. Moreover, the parallel processing model is a natural fit for
structuring such programs and others; some tasks are more easily
conceptualized and coded as components running as independent, parallel
entities.

There are two fundamental ways to get tasks running at the same time
in Python
—
process forks
and
spawned
threads
. Functionally, both rely on underlying operating system
services to run bits of Python code in parallel. Procedurally, they are
very different in terms of interface, portability, and communication. For
instance, at this writing direct process forks are not supported on
Windows under standard Python (though they are under Cygwin Python on
Windows).

By contrast, Python’s thread support works on all major platforms.
Moreover, the
os.spawn
family of calls
provides additional ways to launch programs in a platform-neutral way that
is similar to forks, and the
os.popen
and
os.system
calls and
subprocess
module we
studied in Chapters
2
and
3
can
be used to portably spawn programs with shell commands. The newer
multiprocessing
module offers additional ways to
run processes portably in many contexts.

In this chapter, which is a continuation of our look at system
interfaces available to Python programmers, we explore Python’s built-in
tools for starting tasks in parallel, as well as communicating with those
tasks. In some sense, we’ve already begun doing so—
os.system
,
os.popen
, and
subprocess
, which we learned and applied over
the last three chapters, are a fairly portable way to spawn and speak with
command-line programs, too. We won’t repeat full coverage of those tools
here.

Instead, our emphasis in this chapter is on introducing more direct
techniques—forks, threads, pipes, signals, sockets, and other launching
techniques—and on using Python’s built-in tools that support them, such as
the
os.fork
call and the
threading
,
queue
, and
multiprocessing
modules. In the next chapter
(and in the remainder of this book), we use these techniques in more
realistic programs, so be sure you understand the basics here before
flipping ahead.

One note up front: although the process, thread, and IPC mechanisms
we will explore in this chapter are the primary parallel processing tools
in Python scripts, the third party domain offers additional options which
may serve more advanced or specialized roles. As just one example, the MPI
for Python system allows Python scripts to also employ the Message Passing
Interface (MPI) standard
, allowing Python programs to exploit multiple processors in
various ways (see the Web for details). While such specific extensions are
beyond our scope in this book, the fundamentals of multiprocessing that we
will explore here should apply to more advanced techniques you may
encounter in your parallel futures.

Example 5-1. PP4E\System\Processes\fork1.py

"forks child processes until you type 'q'"
import os
def child():
print('Hello from child',  os.getpid())
os._exit(0)  # else goes back to parent loop
def parent():
while True:
newpid = os.fork()
if newpid == 0:
child()
else:
print('Hello from parent', os.getpid(), newpid)
if input() == 'q': break
parent()

Example 5-2. PP4E\System\Processes\fork-count.py

"""
fork basics: start 5 copies of this program running in parallel with
the original; each copy counts up to 5 on the same stdout stream--forks
copy process memory, including file descriptors; fork doesn't currently
work on Windows without Cygwin: use os.spawnv or multiprocessing on
Windows instead; spawnv is roughly like a fork+exec combination;
"""
import os, time
def counter(count):                                    # run in new process
for i in range(count):
time.sleep(1)                                  # simulate real work
print('[%s] => %s' % (os.getpid(), i))
for i in range(5):
pid = os.fork()
if pid != 0:
print('Process %d spawned' % pid)              # in parent: continue
else:
counter(5)                                     # else in child/new process
os._exit(0)                                    # run function and exit
print('Main process exiting.')                         # parent need not wait

In Examples
5-1
and
5-2
, child processes simply ran a
function within the
Python program and then exited. On Unix-like platforms,
forks are often the basis of starting independently running programs
that are completely different from the program that performed the
fork
call. For instance,
Example 5-3
forks new processes until
we type
q
again, but child processes run a
brand-new program instead of calling a function in the same file.

"starts programs until you type 'q'"
import os
parm = 0
while True:
parm += 1
pid = os.fork()
if pid == 0:                                             # copy process
os.execlp('python', 'python', 'child.py', str(parm)) # overlay program
assert False, 'error starting program'               # shouldn't return
else:
print('Child is', pid)
if input() == 'q': break

If you’ve done much Unix development, the
fork
/
exec
combination will probably look familiar. The main thing to notice is the
os.execlp
call in this code. In a
nutshell, this call replaces (overlays) the program running in the
current process with a brand new program. Because of that, the
combination
of
os.fork
and
os.execlp
means start a new process and run a
new program in that process—in other words, launch a new program in
parallel with the original program.

import os, sys
print('Hello from child', os.getpid(), sys.argv[1])

[C:\...\PP4E\System\Processes]$
python fork-exec.py
Child is 4556
Hello from child 4556 1
Child is 5920
Hello from child 5920 2
Child is 316
Hello from child 316 3
q

./configure
make
make test
sudo make install