Why does `op::via` take an `ExecutorFactory` instead of an `Executor?

[brycelelbach]

op::via currently takes an ExecutorFactory, which seems somewhat unintuitive to me. Consider the following from composition_2.cpp:

template<class CPUExecutor, class IOExecutor>
void sugar(CPUExecutor cpu, IOExecutor io) {
  // ...

  // f on cpu - g on cpu (explicit: the first cpu task runs f and a second cpu task runs g)
  cpu | 
    op::transform([](auto){ return f(); }) | 
    op::via([cpu]{return cpu;}) | 
    op::transform([](f_t ft) {return g(ft);}) | 
    op::submit([](g_t){});

  // ...
}

In the simple and common case, I have to write something like op::via([cpu]{return cpu;}).

IIUC, cpu is a TimeSingleDeferred here.

Why doesn't op::via just take (some sort of) Deferred? This would be much cleaner IMHO.

Looking at the code, it doesn't seem like anything fancy is done with the ExecutorFactory. It's just used once.

BONUS QUESTION: We move from the ExecutorFactory in this capture, but not in this capture. Why?

[kirkshoop]

The reason is that often an algorithm needs to control when a new execution scope begins and ends.

Each execution scope would be sequenced and cancellable independently of another scope from the same factory.

This is how the fork phase of bulkish work is performed. Each call to the same executor factory produces a separate execution scope that is only required to sequence the operations in that scope. Items submitted to different scopes are allowed to run simultaneously.

static_thread_pool::executor() could be the factory function, in which case the pool is what needs to be passed around, not the executor.

ef is moved into the adapter because the via() function is passed a new ef value each time that it is called.
ef is copied into the deferred to support

auto t = op::transform([](auto){ return f(); });
t(cpu) | submit();
t(io) | submit();

it is questionable that this scenario should be supported.. we could make that explicit by making Adapter operator() r-value qualified.