Generally, I have little to add to your excellent points, but I will mention what AFIO does about the concerns you raised: On 3 Jan 2014 at 11:41, Alligand Edouard wrote:
On top of that, you can cancel asynchronous requests. But what to do once the data is written to the disk? Roll it back? Not all file systems are transactional. As you can see the job of the OS isn't the same.
AFIO currently has no ability to cancel scheduled i/o. If someone can suggest how to do this portably, I am all ears.
One of the great difficulty with asynchronous file i/o is that you want asynchronicity but you also want your data to somehow be correctly written to the disk. On the other hand when doing asynchronous network i/o you "just send or receive data". What you do with this data is up to you (from the OS point of view). The contract isn't the same.
Most filing system implementations provide strong guarantees about write reordering e.g. writes will never be reordered by more than thirty seconds. AFIO exposes that very useful property to the author.
My point of view is that sharing a property (in this case asynchronicity) with an existing library does not imply sharing the same philosophy.
There are lots of asynchronous implementations of platform facilities. WinRT is a very good example of implementing much of a platform API asynchronously. I know Microsoft are planning even more asynchronousity to come too, there was a recent news item about experimental new platform layers coming out of MSR. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/