While useful for some simple tasks, I found the old pyprocessing module (on which this is heavily based) to be inadequate for many tasks. It would often crash for various reasons, and because of its signals-based-communication, was often not usable.
Signals in python can only be received by the main thread of execution. Thus, webapps (where the main thread is the one listening for connections), gui programs (where the main thread is the gui thread), and other programs with long-running daemons or main loops are often not usable with pyprocessing.
In the end, I found it easier to use threads for soft-concurrency (I/O-bound), and entirely separate processes with Pyro ( http://pyro.sourceforge.net/ ) for IPC in cpu-bound programs. This has the additional benefit of more easily scaling across machines, which is frequently the next step after scaling within a single machine.
Signals in python can only be received by the main thread of execution. Thus, webapps (where the main thread is the one listening for connections), gui programs (where the main thread is the gui thread), and other programs with long-running daemons or main loops are often not usable with pyprocessing.
In the end, I found it easier to use threads for soft-concurrency (I/O-bound), and entirely separate processes with Pyro ( http://pyro.sourceforge.net/ ) for IPC in cpu-bound programs. This has the additional benefit of more easily scaling across machines, which is frequently the next step after scaling within a single machine.