Re: [boost] [afio] Formal review of Boost.AFIO

Subject: Re: [boost] [afio] Formal review of Boost.AFIO
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-08-25 19:08:42

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.)