Boost logo

Boost :

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

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