future::then can run a continuationSection: 99 [concurr.ts::futures.unique.future] Status: SG1 Submitter: Agustín K-ballo Bergé Opened: 2015-09-03 Last modified: 2021-06-06
Priority: Not Prioritized
View all issues with SG1 status.
Discussion:
Addresses: concurr.ts
In N4538, the continuation given to
future::then can be run "on an unspecified thread of execution". This is too broad, as it allows the
continuation to be run on the main thread, a UI thread, or any other thread. In comparison, functions given to
async run "as if in a new thread of execution", while the Parallelism TS gives less guarantees by running
"in either the invoking thread or in a thread implicitly created by the library to support parallel algorithm execution".
The threads on which the continuation given to future::then can run should be similarly constrained.
[2017-03-01, Kona, SG1]
Agreement that this is a problem. Suggested addition to the issue is below. We have no immediate delivery vehicle for a fix at the moment, but we would like to make the intended direction clear.
There is SG1 consensus that.then continuations should, by default, and in the absence of executors, be run
only in the following ways:
If the future is not ready when .then() is called, the .then argument may be run on the execution
agent that fulfills the promise.
In all cases, the .then argument may be run on an implementation-provided thread, i.e. a thread that is
neither the main thread nor explicitly created by the user.
In the absence of an executor argument (which currently cannot be supplied), running of the .then() continuation
will not block the thread calling .then(), even if the future is ready at the time.
.then caller"
0 | 0 | 5 | 5 | 3
"3. Leave as implementation defined"
1 | 2 | 4 | 3 | 3
"4. Always new execution agent"
2 | 3 | 6 | 2 | 0
The actual conclusion was to allow either (1) or (4) for now, since they are quite close, but present a very different
programming mode from (2).
Proposed resolution: