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