Re: [boost] Futures vs async_result (was: Re: [afio] AFIO review postponed till Monday)

Subject: Re: [boost] Futures vs async_result (was: Re: [afio] AFIO review postponed till Monday)
From: TONGARI J (tongari95_at_[hidden])
Date: 2015-07-24 14:32:52

2015-07-25 1:47 GMT+08:00 Niall Douglas <s_sourceforge_at_[hidden]>:
>
> So tl;dr the reason why futures are more appropriate for AFIO is
> because it's easier to specify ordering of operations with future
> continuations because they always flow in sequence from start to end.
> You can do it with ASIO callback handlers too, but it requires more
> typing, and I think is more error prone and harder for other
> programmers to understand.
>
> The key thing I think those who advocate async_result don't realise
> is you very rarely are adjusting a single file from a single thread
> if you are bothering with async file i/o. In the real world, almost
> certainly multiple threads and processes are all contending on the
> same shared dataset, and you need fine grained control over exactly
> when you do reads and writes with respect to one another.
>
> Hopefully this answer the question?

If async_result can only deal with callbacks, I'd agree with you, but as
already mentioned, it's also capable of futures, just replace the callback
with placeholder like afio::use_future, for example.

I don't know how afio is implemented internally, if using future as its
primitive API does provide performance benefit, then I think it's fine to
just expose the future API, however, if it adds more performance penalty
than callback API, then I think it's conflict with the C++ philosophy - you
don't pay for what you don't use.

Using the proposed `await` with the asio style callback can provide
zero-overhead synchronization as I shown you before, not a single
lock/atomic nor dynamic allocation is needed, while using lightweight
future, you still need to pay for atomic op & dynamic allocation when
chaining the continuations (correct me if I'm wrong).