Boost logo

Boost :

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

On 28/08/2015 13:47, Niall Douglas wrote:
> Thomas has also argued that each async_* function should return only
> a future specific to its return type, so instead of afio::future<T>
> always transporting a future handle in addition to any future T, you
> must supply (I would suppose) two futures to every async_* function,
> one for the handle, the other as the precondition. I asked if he
> could propose an API based on that model which is substantially
> superior to the one used by AFIO, because if he can I'll take it.

I think rather than transporting separate futures he was suggesting
something more like using afio::future<afio::handle_tuple<T>>, where
"future" is a traditional Concurrency future that transports T or errors
and no other state, and "handle_tuple" is a tuple type that transports a
handle (and any other internal state that APIs might want, eg. I think
you mentioned at one point that it also transports the filename of that
handle, for the rmfile case?), plus the desired T for the operation in

ie. separation of types rather than conflation. Personally, I'm not
sure if the extra typing is worth it (and I haven't looked into any
other tradeoffs this might bring), but I can see his point (assuming
that I am correctly interpreting it).

This does of course assume that the handle and the T become ready at the
same time and that they don't have separate error states, but given the
comments in the docs that preconditions are treated as future<void>
anyway and your own comments about default construction on error, I
don't think this is a hardship. Please correct me if I've missed something.

Perhaps a reasonable compromise might be that a handle-transporting
future should be called "handle_future" or "future_handle" or "hfuture"
or similar instead of plain "future", to avoid overloading the buzzword.
  But this might just be bikeshedding again.

Although on a related note, having a single future class with a
handle-part that's non-consuming and a T-part that's consuming seems
potentially confusing. I assume there is some performance argument
behind this design choice..?

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