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

Subject: Re: [boost] [afio] Formal review of Boost.AFIO
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-08-28 01:18:21

On 28/08/2015 15:16, Niall Douglas wrote:
> afio::future<> has a single errored or exceptioned state.

Then FYI, the wording of the first Description paragraph in 
https://boostgsoc13.github.io/boost.afio/doc/html/afio/reference/classes/future.html 
is potentially confusing in that regard, since it seems to be discussing 
error states for "both".

> I suppose you're right, it's not far from being a
> std::future<std::tuple<afio::handle_ptr, T>>. The big problem with
> std::future<std::tuple<afio::handle_ptr, T>> is it's ABI poison
> because of the unknown T passing through an ABI boundary, so you'd
> have to type erase which means an extra memory allocation before
> crossing the ABI.

Perhaps I'm missing something again, but where do you need to do that?

If you mean when passing preconditions back, that could still just 
discard T to void as you're doing now -- assuming you can convert a 
tuple<handle_ptr, T> to tuple<handle_ptr, void> or tuple<handle_ptr>.

Again, I'm not sure how complex this is or whether it would be "worth 
it", but it does seem like a cleaner design to treat the handle and 
other data as the composite value of the future.

Another possibility would be to explicitly separate the handle_ptr. 
Most functions would then change from accepting a future<void> to 
accepting a future<handle_ptr>, since that's the value they actually 
need to do the work.  For dependency order tracking you can just use the 
depends() helper you mentioned earlier, eg:

afio::future<handle_ptr> openfile = afio::async_file(...);
afio::future<void> resizedfile = afio::async_truncate(openfile, 12);
...
afio::future<void> written = afio::async_write(depends(resizedfile, 
openfile), buffers, 0);
...

So the write depends on resizedfile being done, but that *doesn't* carry 
a file handle -- the only one that does is openfile.  (depends, of 
course, would tolerate different Ts for its parameter futures, and will 
return the second one's type.)

This is perhaps more like how people are used to working with futures, 
rather than having them carry around extra values.

The only possibly tricky part that I foresee is that anything calling 
then() will need to know the T of the specific future, but hopefully 
that's trivial in most cases.  (And other than depends()' first 
parameter, you can probably get away with assuming that it's either void 
or handle_ptr most of the time.)