Convert from threading to multiprocessing
- Dominant language
- Python
- Stars
- 0
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
```
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
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.