Closed clayote closed 3 weeks ago
You probably don't want to use the standard concurrent.futures.ProcessPoolExecutor
, because that would send a copy of the whole state of the simulation to every process, every time it runs. I tried that in an old branch, and it was terrible.
The subprocesses used for parallel trigger functions instead synchronize their state with the parent LiSE process every turn, using deltas. A class of Executor
that farms work out to those same subprocesses would do the trick.
You can now use the pool
attribute of a LiSE engine to run some code in a subprocess. It's a pretty normal Executor
.
This supersedes #42.
As of commit 42b7001, LiSE can evaluate trigger functions in subprocesses. The process pools it uses for that could be used for arbitrary work, such as pathfinding, whenever a simulation designer thinks it's useful.