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