2015-07-25 1:47 GMT+08:00 Niall Douglas
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).