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

Subject: Re: [boost] [afio] Formal review of Boost.AFIO
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2015-08-27 09:01:15

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

This is sooo wrong!

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

Not closing a file should be impossible in C++! How can you 'forget' to do
that if your destructor does it (if not done explicitly)? All of this is
sooo wrong!

Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu