On 25 Jul 2015 at 2:32, TONGARI J wrote:
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).
On completion, lightweight futures costs exactly two atomic XCHG to signal and execute continuations (about 40 CPU cycles). It only calls deallocation, one per continuation, after all other processing is completed. The distance between ASIO calling the AFIO completion handler and future continuations being invoked is likely less than 150 CPU cycles. The above is a good example of why zero overhead completion handlers is unimportant for file and filesystem where any operation at all is going to cost > 100 microsecond. ASIO maxes out at about 0.365 microseconds per dispatch amortised. Lightweight future-promise costs about 0.051 microseconds, so that's adding a 14% overhead, and that's at least twice as lightweight as STL future-promise. If your operation costs 100 microseconds, the overhead of a lightweight future-promise is therefore 0.05%. If you were talking about merely chaining pure coroutines, or even socket i/o where *reaction* *time* to a recv() is the important factor rather than overall throughput, I'd get your point entirely. However with file and filesystem reaction time is not remotely important at all because it's overall latency and throughput which matters, not the time between when an i/o completes and you do something with it. My personal opinion is that for 99% of anyone doing async file or filesystem that the choice of lightweight future promise as the completion mechanism chosen is just not an issue. Hence the choice to use them over async_result because they are what the STL has chosen as the standard async notiifcation mechanism, and are therefore unsurprising to most C++ programmers. I also hear rumours that the Networking TS may yet enforce futures for all networking, so the choice of futures by AFIO should not be controversial. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/