Re: [boost] library to support async/await pattern

Subject: Re: [boost] library to support async/await pattern
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2013-04-20 13:45:05

On Sat, Apr 20, 2013 at 12:03 PM, Oliver Kowalke
<oliver.kowalke_at_[hidden]> wrote:
> 2013/4/20 Valentin Milea <valentin.milea_at_[hidden]>
>
[...]
>
>> I'm not sure how a boost::task wrapper would be implemented over Asio API.
>> Run it as a subtask and trigger some condition variable in Asio callback?
>>
>
> I wasn't thinking about an asio wrapper - it might be require a new library
> (maybe worth of investigation).
> I supect that boost.task would fit here (as a wrapper for coop. operations
> wrapping boost.asio).
>

I do not believe in wrappers. There are too many async libraries out
there to write wrappers for each one.
A good coroutine/task library should be able to work with existing
APIs transparently. I like a future/promise approach, something like
this:

    future<error_type> accept_error;
    future<error_type> connect_error;

    acceptor->async_accept(sink,
                           accept_error.promise());

    source.async_connect(*endpoint,
                         connect_error.promise());

    // scheduler is the coroutine to pass control to while wainting.
    wait_all(scheduler, connect_error, accept_error);

    assert(connect_error);
    assert(accept_error);

I have implemented the previous syntax in my sandbox:

https://github.com/gpderetta/Experiments/blob/master/tests/asio_test.cc

but something similar should be easily implementable on top of
boost.coroutine or boost.taks. In principle the above could be
implemented with any future that support the .then syntax, like a
boost::future or the proposed extension to std::future. Still, as
these are quite heavyweight, a custom future type could be implemented
(maybe: does the boost::future 'then' implementation require going
through the internal future mutex or is it invoked immediately when
the promise is fulfilled? a cursory glance at the implementation shows
that the lock is always taken) .

-- gpd