LeeHowes
commented
6 years ago What I envisage is a model like the following.
An executor that supports delegation will expose: Executor {.... void delegate_to(Executor); }
So when that is called as e.delegate_to(e2);
That method has the semantics that a may enqueue zero or more tasks onto b, with the expectation that they run. Those tasks may be enqueued at any point that happens after the entry to the delegate_to call and before a is destroyed. That enqueue will be guaranteed to happen by the following sequence (that needs checking to make sure we can make this work with an active queue):
- It will check for work to run.
- e will atomically store a reference to e2.
- If work is already sitting in a waiting to be run, the delegate_to method will immediately drain it into b.
- When any work is enqueued onto a, if a reference to a delegatee is set that work will be enqueued directly through onto b under the forward progress guarantee of the agent completing the work, not a.
- Work is now in b and can run under b's guarantee.
There is no requirement that these tasks be the actual tasks to complete, only that these tasks ensure that the work makes progress once they are run by b. So unlocking the semaphore to free a thread would be a valid task, as would flushing a GPU work queue.
We would have to make sure we can make this model work in the presence of multiple delegatees.
It is an open question whether forward progress delegation happens at data-flow granularity, driven by futures, or at agent granularity, driven by executors. From an implementation point of view, the latter seems easier to deal with. This can be achieved by connecting executors together at the point of converting one future type to another.
For example, in: auto f2 = f.via(e).then(task).via(e2).then(task2); f2.get();
e should be allowed to be an agent with weak forward progress guarantees (so weak as to make no independent forward progress at all in the form of a purely delayed executor as used in folly::SemiFuture::defer).
f2.get() should ensure that e2 makes progress. e2 should make sure that e does. The full chain allows deferral from e through e2 to the inline caller (or its implied executor).