Convert from threading to multiprocessing

[GoogleCodeExporter]

I think that it's worth considering converting actor.py and the other core
classes of scipysim from using the threading library to using the
multiprocessing library
[http://docs.python.org/dev/library/multiprocessing.html]. Doing so seems
like it'd bring several advantages:

 1. It would allow us to avoid the performance problems associated with the
Global Interpreter Lock, which is likely to become a problem as we move to
larger models.

 2. It would put us in a position to take advantage of multicore systems,
which is nominally one of the benefits of using the "directorless" style
that we've adopted (and seems likely to be increasingly important in coming
years).

 3. It appears that it might resolve the threading problems that we
previously ran into with matplotlib, allowing us to implement real-time
plotting.

Since we already require Python >= 2.6 for other reasons I don't see any
problems with version compatibility. The only obvious drawback I can see at
this point is that the multiprocessing library apparently suffers from low
performance on Windows (which seems to have fairly heavyweight processes).
Perhaps we could consider having actors (and the display) revert to the
current threaded implementation when running on Windows.

Original issue reported on code.google.com by allan.mcinnes@gmail.com on 8 May 2010 at 8:52

[GoogleCodeExporter]

I've modified the Actor and Channel classes to use composition rather than 
inheritance to incorporate Threads. This paves the way for allowing a choice to 
be made between Threads, Processes, or even a custom lightweight scheduler 
(perhaps a sequential Discrete-Event scheduler). 

Original comment by allan.mcinnes@gmail.com on 9 Jun 2011 at 12:40