Re: [boost] [afio] AFIO review postponed till Monday

Subject: Re: [boost] [afio] AFIO review postponed till Monday
From: TONGARI J (tongari95_at_[hidden])
Date: 2015-07-21 23:12:20

2015-07-22 9:27 GMT+08:00 Niall Douglas <s_sourceforge_at_[hidden]>:

>
> Quite a few people have disliked (a) the choice of future
> continuations over ASIO's async_result pattern and (b) the batch API.
> Those two observations have come up repeatedly - Bjorn and Robert on
> this list have both publicly found issue there, and neither was alone
> in their opinion.
>
> I'm not dropping futures in favour of async_result - I don't think
> that helps ease of use because in file i/o you really do want strong
> i/o ordering, and you usually don't care about ordering much for
> network i/o. Forthcoming C++ 1z coroutines are also futures based,
> and that decision is not going to be reversed now. Futures are our
> future as it were.
>

async_result is more flexible and it allows the use of future, e.g.
`s.async_xxx(..., asio::use_future)`, and you can customize your
afio::use_future to use your lightweight futures.
What's your real concern of async_result? The verbosity of specifying
afio::use_future?
Since you mentioned C++ 1z coroutines, the asio way actually allows
zero-overhead adaption without using a future, e.g. see:
https://github.com/jamboree/act

Is any performance reason in preferring strict future API to the callback
style?