Movatterモバイル変換

This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofC++14 status.

2186. Incomplete action onasync/launch::deferred

Section: 32.10.9[futures.async]Status:C++14Submitter: Vicente J. Botet EscribaOpened: 2012-09-20Last modified: 2017-07-05

Priority:Not Prioritized

View otheractive issues in [futures.async].

View all otherissues in [futures.async].

View all issues withC++14 status.

Discussion:

The description of the effects ofasync when the launch policy islaunch::deferred doesn't state what is done with the result of the deferred function invocation and the possible exceptions as it is done for the asynchronous function when the policy islaunch::async.

[2012, Portland: move to Open]

Detlef: agree with the problem but not with the resolution. The wording should be applied to all launch policies rather than having to be separately specified for each one.

Hans: we should redraft to factor out the proposed text outside the two bullets. Needs to be carefully worded to be compatible with the resolution of2120⁽ⁱ⁾ (see above).

Moved to open

[Issaquah 2014-02-11: Move to Immediate after SG1 review]

Proposed resolution:

[This wording is relative to N3376.]

1. Change 32.10.9[futures.async] p3 bullet 2 as indicated:

   template <class F, class... Args>future<typename result_of<typename decay<F>::type(typename decay<Args>::type...)>::type>async(F&& f, Args&&... args);template <class F, class... Args>future<typename result_of<typename decay<F>::type(typename decay<Args>::type...)>::type>async(launch policy, F&& f, Args&&... args);

   -2-Requires: […]

   -3-Effects:: The first function behaves the same as a call to the second function with apolicy argument oflaunch::async | launch::deferred and the same arguments forF andArgs. […] The further behavior of the second function depends on thepolicy argument as follows (if more than one of these conditionsapplies, the implementation may choose any of the corresponding policies):

   • ifpolicy & launch::async is non-zero […]

   • ifpolicy & launch::deferred is non-zero — StoresDECAY_COPY(std::forward<F>(f)) andDECAY_COPY(std::forward<Args>(args))... in the shared state. These copies off andargsconstitute adeferred function. Invocation of the deferred function evaluatesINVOKE(std::move(g), std::move(xyz)) whereg is the stored value ofDECAY_COPY(std::forward<F>(f)) andxyz isthe stored copy ofDECAY_COPY(std::forward<Args>(args))....Any return value is stored as the result in the shared state. Any exception propagated from the execution of the deferred function is stored as the exceptional result in the shared state. The shared state is not made ready until the function has completed. The first call to a non-timed waiting function (32.10.5[futures.state]) on an asynchronous return object referring to this shared state shall invoke the deferred function in the thread that called the waiting function. Once evaluation ofINVOKE(std::move(g), std::move(xyz)) begins, the function is no longer considered deferred. [Note: If this policy is specified together with other policies, such as when using a policy value oflaunch::async | launch::deferred, implementations should defer invocation or the selection of thepolicy when no more concurrency can be effectively exploited. —end note]