Aha: 13.2.2 table 4:

x1.defer(std::move(f), a) 

Effects: Creates an object f1 initialized with DECAY_COPY(std::forward(f)) in the current thread of execution. Calls f1() at most once. The executor shall not block forward progress of the caller pending completion of f1(). The executor should not begin f1’s progress before the call to defer completes. [ Note: One use of defer is to convey the intention of the caller that f1 is a continuation of the current call context. The executor may use this information to optimize or otherwise adjust the way in which f1 is invoked. — end note ] Executor implementations should use the supplied allocator to allocate any memory required to store the function object. Prior to invoking the function object, the executor shall deallocate any memory allocated. [ Note: Executors defined in this Technical Specification always use the supplied allocator unless otherwise specified. — end note ] Synchronization: The invocation of defer synchronizes with (C++ 2014 [intro.multithread]) the invocation of f1.

On 5 January 2018 at 17:02, Klaim - Joël Lamotte via Boost-users <boost-users@lists.boost.org> wrote:

On 5 January 2018 at 16:55, Vinnie Falco via Boost-users <boost-users@lists.boost.org> wrote:
On Fri, Jan 5, 2018 at 7:53 AM, Richard Hodges via Boost-users
<boost-users@lists.boost.org> wrote:
> Perhaps defer does a post
> unless the handler is a continuation? I think that would make sense.

And how would it know if the handler is a continuation?

I think defer imply that the provided handler is a continuation.
There are similar mechanisms proposed in the Executor proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0761r1.pdf
(see page 6).

Joël Lamotte

Boost-users mailing list