Boost logo

Boost :

Subject: Re: [boost] [afio] AFIO review postponed till Monday
From: Ben Pope (benpope81_at_[hidden])
Date: 2015-07-22 17:37:10


On Thursday, July 23, 2015 12:01 AM, Niall Douglas wrote:
> On 22 Jul 2015 at 11:12, TONGARI J wrote:
>
>>> 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
>
> A good summary of why those who prefer async_result do so, thank you.
>
>> Is any performance reason in preferring strict future API to the callback
>> style?
>
> Historically futures were slower, and Chris said so repeatedly in
> N-papers to WG21.
>
> I believe lightweight futures have eliminated the performance gap. I
> also have an extension to the Concurrency TS in that you can add as
> many const lvalue ref continuations as you like to lightweight
> futures, not just a single rvalue ref continuation as per the TS.
>
> This effectively implements a single shot signals and slots
> implementation - you can install as many completion handlers as you
> like per future.
>
> None of this answers your question of course. I will say that file
> i/o is often 10x-1,000,000x slower than network i/o, and the
> performance of handlers vs continuations is correspondingly
> unimportant.
>
> Futures gives you the option of monadic programming, and they enforce
> strict operation ordering very succintly. They are the right choice
> for file i/o, just as async_result is the right choice for network
> i/o.
>
> Though, to be honest, I suspect lightweight futures will make
> async_result not as useful as previously.

To clarify; I think you're saying that your lightweight futures are
close enough to free that you would prefer to implement your library
with them as opposed to callback hell; and so, presenting the nicer
future API poses no significant further performance penalty whilst
presenting a nicer syntactic model.

Personally I'm really interested in your lightweight futures for the
same reason. Callback hell sucks; without profile information to the
contrary, I'd rather just write code the nice way.

Ben


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk