[cpp-threads] Asynchronous Function Proposal

[Lawrence Crowl]

On 6/1/09, Anthony Williams <anthony at justsoftwaresolutions.co.uk> wrote:
> Beman Dawes wrote:
> > On May 31, 2009, Lawrence Crowl <Lawrence at crowl.org> wrote:
> > >
> > > 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.
>
> Just to address this particular point:
>
> I don't think we need a new async_future: the current
> unique_future/shared_future set is fine. The problem is on the side
> of the code that *sets* the future value. As pointed out in N2880,
> there is no way to ensure that the future is made ready *after*
> thread-local variables have been destroyed *if you stick to the
> public interface in the current standard*.
>
> However, async would be a standard-library function, so can use
> implementation-specific magic to ensure that the thread-locals
> *are* destroyed before the future is made ready.
>
> Using a special async_future type essentially says that the
> thread-local issue is insoluble. I still hope we can find a way
> to solve this problem that we can expose as part of the public
> interface to the C++0x thread library.

While I agree with the analysis, I wanted a proposal on the table
that could work with what we have.  I fully concede that the proposal
is therefore somewhat incremental.

-- 
Lawrence Crowl