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

Subject: Re: [boost] [afio] Formal review of Boost.AFIO
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-08-27 23:16:22

On 28 Aug 2015 at 14:48, Gavin Lambert wrote:

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

BTW where the file is open and the platform supports it, AFIO deletes 
via file descriptor not by name. A third party process could be 
looping renames of that file and it would still work perfectly.

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

I can see his point too, hence the engagement. Using a tuple handle + 
T transport is interesting. Definitely better than separate futures.

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

afio::future<> has a single errored or exceptioned state. 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.

With the AFIO API design we never send an unknown T across an ABI 
boundary.

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

Not at all. It led to less code being typed by the end user, that's 
all.

Normally whenever that happens I hear alarm bells, because less 
typing often opens unintended consequences. But I am unaware of any 
related to the split consuming-nonconsuming future semantics in the 
AFIO API design. I do think there are some question marks elsewhere 
in the AFIO API design, as I've mentioned in other threads.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/