when_all should be described explicitly as not intrinsically parallel

[BenFrantzDale]

Coming from CPU-parallel programming, I expected when_all to be used as a customization point like bulk your allow schedulers to kick off parallelism. After discussion with @lewissbaker and others, it became clear that that’s not the design intent and that when_all is intended to be just the “join” part of a split/join, where the expected usage for CPU-parallel computing is when_all(schedule_on(sch, snd0), schedule_on(sch, snd1)).

I think the wording should do more to explicitly state that when_all is intended to not be parallel so people don’t write schedulers that customize it like that and don’t write algorithms assuming it parallelizes.

(I could see permitting when_all you schedule each of its senders, e.g., if the scheduler knows it has an abnormally small stack size.)

Related: #277

[lewissbaker]

The child tasks of when_all are potentially concurrent, but are not guaranteed/required to run concurrently. All of the child tasks are started from a single thread - once started, it is up to each child task how/where they execute.

The wording in [exec.when.all] seems to specify the intended semantics for the default implementation. However, it does not currently describe what the requirements are for any customisation of the when_all algorithm. Ideally, the wording would specify the aspects of the behaviour that are required for any customisation of this algorithm.