[cpp-threads] Asynchronous Function Proposal

[Beman Dawes]

On Sun, May 31, 2009 at 6:59 PM, Lawrence Crowl <Lawrence at crowl.org> wrote:
> Please take a look at the attacked draft proposal for the async
> function.  Comments are encouraged.

> Policies
>
> The async functions have a policy parameter. Three policies are
> defined in this paper. ...

I think of a "Policy" as a mixin or some similar technique that lets
users supply their own flavors. Typically the policy is a template
parameter, with a concept that defines its requirements. That way the
user can supply a thread-pool based policy, even if the standard
library doesn't yet supply a thread-pool.

I don't have any idea if this is feasible for async. If it isn't,
perhaps your "Policies" should renamed "Options" so that the name does
raise false expectations.

> Future
>
> The proposal includes a new future type because it cannot provide the
> full interface of the existing futures.
>
> * The value get must join with the thread performing the work to
> ensure that all thread-local variables have been destroyed before
> execution of code depending on the return value. Unfortunately, the
> thread class has no timed join, so the async_future cannot support a
> timed_wait.
>
> * The thread class has neither query to determine if the
> thread has finished nor a try_join operation. Thus, one cannot
> implement an is_ready query that includes the fact that all
> thread-local variables have been destroyed.
>
> * Sequential execution
> defers invocation of the work until the get call, which means that
> the value versus exception result of a function is unknown until that
> time. So, the has_value and has_exception queries cannot provide
> meaningful results before then.

As Herb pointed out, this makes it look like we have serious problems
with the current future interface and/or the current thread interface.
I very much want to hear what Howard, Anthony, and others with a deep
understanding of standard library threads/futures/promises have to say
about these issues.

I also share Herb's concern about the apparent complexity of an eight
function interface. We can do better than that!

Once the interface settles down, there is the question of
implementation and experience. Asynchronous parallelism isn't
something I'm willing to accept based on armchair analysis. I'd want
to see an implementation in the hands of at least a few POSIX and
Windows users before signing off on something as critical to the
perception of the C++0x standard library as this will be.

Lawrence, please don't take any of the above comments personally! Your
work is much appreciated!

--Beman