On 26/08/2015 02:02, Niall Douglas wrote:
On 25 Aug 2015 at 20:22, Gavin Lambert wrote:
Out of curiosity, in the Hello World example, is there any benefit of using when_all_p on all individual futures instead of merely waiting for the "read" future alone?
Since all the previous futures are cascaded to "read", any errors raised by earlier ops should be cascaded to the later ops anyway, so "read" should succeed only if all prior ops succeed (and presumably not even be attempted if prior ops failed). Or are you doing something different with errors?
I do apologise. There was a whole page in there on the error handling semantics. I appear to have deleted it, and I have logged the issue at https://github.com/BoostGSoC13/boost.afio/issues/96. That's a major boo boo on me.
What happens is that an errored input future is treated as if a default constructed input future. So, for this sequence:
auto a=async_file(); auto b=async_read(a); auto c=async_truncate(b); auto d=async_close(c);
If b became errored, the truncate would try to truncate a default constructed handle i.e. not a valid file descriptor. c would therefore become errored with "not a valid file descriptor" or whatever error the OS returns for that situation.
In this sense, you're right that an error will *probably* cascade into dependent operations. But AFIO is deliberately stupid, and lets the OS decide what is valid input and what is not, and it returns back whatever the OS tells it.
Is this a wise design? I felt it has the advantage of simplicity, and there is something to that.
So just for clarity, this does mean that the file will not be deleted in that example (in case of earlier error), yes? (I assume it will eventually be closed once the futures that did succeed fall out of scope.)