Boost logo

Boost :

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

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


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at