Re: [boost] [AFIO] Callback API

Subject: Re: [boost] [AFIO] Callback API
From: Alligand Edouard (edouard.alligand_at_[hidden])
Date: 2014-01-03 06:41:42

> [1]: This is a very tl;dr discussion worthy of a 90 minute presentation, but in
> short yes this is true on all mainstream operating systems. Linux *can* turn on
> non-blocking for file handles, but the feature has "dragons live here" all over it.
> On Windows an overlapped file i/o operation can and does go synchronous on
> many an occasion - I've seen an overlapped WriteFile() take 1.6 seconds to
> return "operation in progress".

To add to the discussion with an example (at the risk of repeating what may have been better said): to understand how nightmarish file i/o can be, you just need to think about network file storage. Imagine that you want to write to a NAS whose disks are currently sleeping. It may (or may not, depending on the write request and the configuration of the NAS) require the disk to spin up just to acknowledge the request, because it's not the same error to have a non-working device, a privilege error or a full disk (and these are just examples I can think of).

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. 

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.

My point of view is that sharing a property (in this case asynchronicity) with an existing library does not imply sharing the same philosophy.

Kind regards.

--Edouard