Re: [boost] [afio][v1.30 "C++ Now edition" released]

Subject: Re: [boost] [afio][v1.30 "C++ Now edition" released]
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-03-19 21:05:39

On 19 Mar 2015 at 21:26, Mathias Gaunard wrote:

> So v1.4 will be the interface that will be submitted for inclusion into 
> Boost?

v1.0 was the interface submitted for inclusion into Boost. It 
reflected the state of C++ in 2013 where XP compatibility was still 
very important, and therefore so was VS2010 compatibility. Every 
version thence is also submitted for inclusion until a review 
happens, which I assume will come back with a long list of changes 
needed anyway.

If you're really asking when would I expect to finish the major 
refactoring, currently I expect v1.4 to be the last. However, I 
thought that about v1.3 during v1.2.

A lot of this is outside my control of course. Had WG21 gone for 
Chris's concurrency proposal for example, I'd be refactoring in a 
very different direction. This is a big consequence of being the 
first C++ 11 only Boost library to enter the community review queue - 
you build in not just your own technical debt, but also the technical 
debt of the C++ language itself, *plus* that of the Microsoft 
compiler team, the libstdc++ team, the mingw team and so on. In fact 
the oldest compiler from v1.0 still supported identically is clang, 
because they had the most complete C++ 11 support the earliest, so 
clang 3.2 still works perfectly. As the ecosystem collectively 
reaches closer to conformance to the standard and therefore to each 
other, I can keep ripping out workaround patterns which used to make 
sense before but don't anymore.

I'll put this another way. Back in v1.0 future-promise looked fast 
and buggy, but then the engine could only push 150k ops/sec. By v1.2 
future-promise looked slow because it could now push 1.5m ops/sec. So 
by me ripping out the shared_ptr workarounds, I made the performance 
spotlight fall on other code. As I fix that, spotlights shine 
elsewhere and more fixes are needed.

At some point both the C++ language ecosystem changes will settle 
down, and nails will stop sticking up to be hammered down. I'd expect 
API maturity to start then, same as any other Boost library. At that 
point I'll start building the embedded graph database AFIO is 
intended for.

> > AFIO uses ASIO's event loop. It doesn't use the async_result idiom of
> > ASIO because for file i/o you want strong graph ordering, and that's
> > a pain to do with async_result. A more functional idiom, for which I
> > chose future-promise, makes strong ordering much easier to program.
> > Once I get Fibers/resumable function support in there next release,
> > writing strongly graph ordered filing system algorithms ought to
> > become optimally easy, and then I can get down to writing race free
> > tree visitors etc which right now are very messy to write and debug.
> 
> I think it would be useful to be able to make use of the future-promise 
> idiom for other ASIO code as well.

ASIO already provides future-promise support via asio::use_future.

> Is it possible to use your futures for any ASIO async_result?

Absolutely. Mine has just standard shared_futures, same as the ones 
ASIO uses.

The custom afio::future in v1.4 will also work perfectly in ASIO, 
indeed I'll be providing the async_result specialisations so it's 
just as seamless to use. ASIO has Fiber support too, so Fiber should 
seamlessly multiplex ASIO and AFIO i/o for you. You just glue 
together the logic with resumable functions, and let the runtime 
figure it out for you. Which will be neat.

Niall

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