Setting at Sun Mar 7 18:37:30 2010
...Ctrl-C to exit...Generally speaking, signals must be used with cautions not made obvious by the ex-
amples we’ve just seen. For instance, some system calls don’t react well to being inter-
rupted by signals, and only the main thread can install signal handlers and respond to
signals in a multithreaded program.
When used well, though, signals provide an event-based communication mechanism.
They are less powerful than data streams such as pipes, but are sufficient in situations
in which you just need to tell a program that something important has occurred and
don’t need to pass along any details about the event itself. Signals are sometimes also
combined with other IPC tools. For example, an initial signal may inform a program
that a client wishes to communicate over a named pipe—the equivalent of tapping
someone’s shoulder to get their attention before speaking. Most platforms reserve one
or more SIGUSR signal numbers for user-defined events of this sort. Such an integration
structure is sometimes an alternative to running a blocking input call in a spawned
thread.
See also the os.kill(pid, sig) call for sending signals to known processes from within
a Python script on Unix-like platforms, much like the kill shell command used earlier;
the required process ID can be obtained from the os.fork call’s child process ID return
value or from other interfaces. Like os.fork, this call is also available in Cygwin Python,
but not in standard Windows Python. Also watch for the discussion about using signal
handlers to clean up “zombie” processes in Chapter 12.
The multiprocessing Module
Now that you know about IPC alternatives and have had a chance to explore processes,
threads, and both process nonportability and thread GIL limitations, it turns out that
there is another alternative, which aims to provide just the best of both worlds. As
mentioned earlier, Python’s standard library multiprocessing module package allows
scripts to spawn processes using an API very similar to the threading module.
This relatively new package works on both Unix and Windows, unlike low-level process
forks. It supports a process spawning model which is largely platform-neutral, and
provides tools for related goals, such as IPC, including locks, pipes, and queues. In
addition, because it uses processes instead of threads to run code in parallel, it effec-
tively works around the limitations of the thread GIL. Hence, multiprocessing allows
the programmer to leverage the capacity of multiple processors for parallel tasks, while
retaining much of the simplicity and portability of the threading model.
Why multiprocessing?
So why learn yet another parallel processing paradigm and toolkit, when we already
have the threads, processes, and IPC tools like sockets, pipes, and thread queues that
The multiprocessing Module| 243