Currently if you use the default Runner with more than 1 concurrent task, your run will be nondeterministic because the concurrent tasks can finish in different orders.
We could relatively easily add another strategy to the runner where it sends out N tasks initially, then waits for the first of these to come back before issuing a new point, then waits for the second to come back etc.
The advantage of this strategy would be deterministic runs even with >1 tasks running asynchronously, the disadvantage would be potentially inefficient resource usage (imagine what would happen if the first point took ages to come back).
IIRC we wanted to abstract out this concept of "runner strategy" anyway, so this could be a good opportunity to do that.
Currently if you use the default Runner with more than 1 concurrent task, your run will be nondeterministic because the concurrent tasks can finish in different orders.
We could relatively easily add another strategy to the runner where it sends out N tasks initially, then waits for the first of these to come back before issuing a new point, then waits for the second to come back etc.
The advantage of this strategy would be deterministic runs even with >1 tasks running asynchronously, the disadvantage would be potentially inefficient resource usage (imagine what would happen if the first point took ages to come back).
IIRC we wanted to abstract out this concept of "runner strategy" anyway, so this could be a good opportunity to do that.