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

Subject: Re: [boost] [afio] Formal review of Boost.AFIO
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-08-25 10:02:12

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.

> On an unrelated note, I know that this has come up before but I do think 
> that you should have a rationale section on use of internal APIs on 
> Windows; why you're doing that, and benefits and caveats.  (They're not 
> undocumented APIs as some claim, but they *are* subsystem-layer APIs and 
> as such aren't guaranteed to behave the same way on different Windows 
> versions, particularly future ones, as they're expected to be used only 
> by code that is upgraded at the same time as Windows itself.  How likely 
> that is to be a real issue I don't know, but it seems at least worthy of 
> mention.)

Logged at https://github.com/BoostGSoC13/boost.afio/issues/81.

Thanks Gavin.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/