[cpp-threads] Asynchronous Function Proposal

[Herb Sutter]

Summary of my main suggested changes to the proposal:

  - The async policy should be an enum (or similar), not a set of tag types.

  - Remove variadic overloads, put async policy last with a default arg.
    (Can't do this with tag types.)

  - async() should return a unique_future, not a new kind of future
    (a new type is overkill and creates problems, e.g., that the current
    proposal doesn't allow getting a shared_future to an async() call;
    that problem was already solved by unique_future).

  - The synchronous policy should semantically mean executing at the call
    point, not at get().


I wrote:
> > So I would (strongly) suggest having only:
> >
> >  enum AsyncPolicy {
> >    /* default, might run synchronously or asynchronously */ ,
> >    /* guaranteed to run asynchronously on another thread */ ,
> >    /* guaranteed to run synchronously on this thread */
> >  };
> >
> > That boils it down to the two important and mutually exclusive
> > cases the user cares about and an "implementation-defined" default,
> > which is complete and readily explainable. Is there a need for
> > something more?

Lawrence wrote:
> But those policies are what I proposed, 

Yes and no:

Yes, you proposed those three and I agree those are the right ones. I was responding to Peter's note about more kinds of policies being 'core' (they aren't to me).

But no, in the proposal they are not enumerators. Peter made a good suggestion that these be enums or otherwise easy to specify at run time, which also avoids proliferating overloads of tag types.


> where "this thread" is
> defined as the thread that calls get().

I didn't notice that -- I think that's wrong. First, the synchronous case should be the same as if the user hadn't written async() around it. Second, there can be multiple gets due to shared_future (see below).


Also, what do you think of the other suggested changes:

  - The policy parameter should go last and have a default argument, for symmetry with other stdlib practice (e.g., atomic<T> memory order policies).

  - Therefore, and for other reasons, we shouldn't provide the variadic form, and instead provide only the one form "future<...> async( F&&, AsyncPolicy = could_be_sync_or_async".

  - We shouldn't propose a third future type. This one should return unique_future (and that and shared_future should be fixed if deemed necessary). Note that this fixes a usability issue with the current proposal, namely that the user can't put the result in a shared_future if copying is required.

?
  

Thanks again for the work on this! I think in Kona I promised to write up this async launcher proposal but then never did -- sorry.

Herb