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-27 01:27:07

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?
[...]
> What happens is that an errored input future is treated as if a
> default constructed input future. So, for this sequence:
[...]
> 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.

Just to rehash this point a little -- in the "Exception Model" section 
on pretty much all the functions it explicitly states that it propagates 
the exception of input preconditions.

To me, this implies that the same should apply to error codes -- if the 
input precondition has an error code, then the function should output 
the *same* error code without attempting to perform the operation (and 
in particular not losing the original error code and replacing it with a 
"handle not valid" error code, which would almost certainly be the 
result of actually calling the OS function).

I know that error codes and exceptions are technically different, but 
other than having different performance characteristics I think that 
they should be treated logically the same.  (I think I've mentioned this 
before.)

Where this might fall down of course is that if you're just blindly 
exposing OS error codes, you might have codes that aren't actually 
errors, like "no more items" following an enumeration operation.  Other 
than handling and concealing that internally (which might not be 
feasible depending on the API) I'm not sure of a good solution to this, 
unless there's a generic way to tell whether a given code is a "success" 
or a real failure (which is somewhat possible on Windows for HRESULT- or 
NTSTATUS-based APIs but not on POSIX or basic Win32 APIs, AFAIK).