Split Environment.run() into two (async) parts - WIP

[motus]

Everything is broken atm

[bpkroth]

High level design though: why split run at all?

Why not keep the current idea: setup(), run(), teardown() are all synchronous.
That would make it easier to keep the semantics for CompositeEnvs as well, otherwise we need to start expressing which parts of those can be parallelized or not.

Instead, I propose making a new "Worker" concept.

Worker can be assigned an Environment to take through the entire setup, run, teardown phase.

Then, the Scheduler, can have a pool of Workers, that it runs asynchronously, e.g., in separate processes or threads.

See Also #380 for some design note details.

[bpkroth]

High level design though: why split run at all?

Why not keep the current idea: setup(), run(), teardown() are all synchronous. That would make it easier to keep the semantics for CompositeEnvs as well, otherwise we need to start expressing which parts of those can be parallelized or not.

Instead, I propose making a new "Worker" concept.

Worker can be assigned an Environment to take through the entire setup, run, teardown phase.

Then, the Scheduler, can have a pool of Workers, that it runs asynchronously, e.g., in separate processes or threads.

See Also #380 for some design note details.

FWIW, I have some async status polling work started that builds off of this idea:

TrialRunner (Worker) class walks an Environment thru the setup/run/teardown phases.
It also gets an EventContextLoop to run background tasks with.
The base run phase is augmented to also start a background async status poll using that EventContextLoop.

I'll try and post a PR when I have something working a little better end-to-end.

[motus]

Abandoning in favor of multithreaded wrapper around a synchronous Environment class. Might resume that work later