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-26 22:16:15

On 26 Aug 2015 at 11:08, Gavin Lambert wrote:

> > 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?

In the sequence:

auto a=async_file();
auto b=async_read(a);
auto c=async_truncate(b);
auto d=async_rmfile(c);
auto e=async_close(d);

... you are explicitly saying do not execute later steps if an 
earlier step fails. It defaults to this as this is probably safest 
and least surprising.

If on the other hand you DO always want to delete and close the file 
no matter what happened before you would write:

auto a=async_file();
auto b=async_read(a);
auto c=async_truncate(b);
auto d=async_rmfile(depends(c, a));
auto e=async_close(d);

The depends(precondition, input) function swaps the second future for 
the first when the first completes. It is implemented as:

precondition.then([input](future &&f) { return input; }

It occurs to me that the above is exactly what should be on a first 
page of a tutorial. To be honest, it never occurred to me the above 
wasn't totally obvious. So I've logged that to 
https://github.com/BoostGSoC13/boost.afio/issues/97.

Thanks Gavin.

> (I assume it will eventually be closed once the futures that did succeed
> fall out of scope.) 

You should always explicitly issue async_close() when you can because 
closing a file handle can be very expensive on Windows and OS X.

If you forget, when shared_ptr count hits zero the handle is 
destructed and the handle fsynced (if flags say so) and closed 
synchronously. I have a todo item that I really should either detach 
destructor induced handle closes as I can't throw up any exceptions 
which occur anyway, or fatally exit the process because you forgot to 
close the handle. One or the other (user selectable of course).

Niall

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