Re: [boost] This AFIO review (was: Re: [afio] AFIO review postponed till Monday)

Subject: Re: [boost] This AFIO review (was: Re: [afio] AFIO review postponed till Monday)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-08-22 20:38:07

On 22 Aug 2015 at 19:43, Glen Fernandes wrote:

> Hartmut makes a good point. Niall, please correct me if my
> understanding is lacking here:
> - You are presenting this library with interface version A
> - You plan to implement interface version B while also providing A for
> backward compatibility
> - Once B is implemented, all documentation will only ever mention B
> because it is superior
> - The benefits of B make it superior in every way to A

Your understanding is lacking.

v1.3 AFIO is the old, very well tested, mature engine with the 
original API from GSoC 2013. It is reliable, won't lose you data, 
exposes the POSIX race freedom guarantees, and is a good solid base 
for any file system application. It is not particularly friendly to 
program with, or at least that's what everyone has told me.

v1.4 AFIO is the library being presented here. It has a new, much 
more friendly API which should address all the usability concerns 
people have expressed over the past two years.

The *internal* *implementation* of the v1.4 AFIO you are being 
presented with is currently implemented internally using the v1.3 
engine. That makes it just as reliable, just as well tested, just as 
solid a base for a database application as v1.3 AFIO is, except it is 
now easier to program against. A later *internal* implementation will 
be completely new, but that isn't important to this review because 
little external changes. Code written now still works later, just 
faster. Every Boost library sees substantial internal refactoring 
over time, AFIO is no different.

Check out the tutorial yourself. If you think the API presented looks 
well designed and easy to use, if all the unit tests pass and have 
good coverage, if you think the documentation is up to scratch, if 
you feel the error handling is well implemented then vote for 
acceptance, with the condition I must return for an additional 
mini-review later if you like.

If you feel the design of the API is fundamentally flawed, the unit 
tests are useless, the documentation rubbish, then vote for 
rejection.

> >> The library being presented today is very well tested, and should
> >> *not* *lose* *you* *data* which is the most important quality in an
> >> i/o library. Even if performance - as you will see in the tutorial's
> >> benchmarks - is a bit poor in the current engine in some use cases.
> 
> I'm interested in an asynchronous file I/O library being part of Boost
> for performance (portably). As long as it is no less reliable than
> using the native filesystem APIs, reliability isn't a concern or a big
> selling point for me.

As the documentation lists out in great detail, and including a table 
of race guarantees per API in the reference docs and a table of what 
guarantees are available on each well known filing system, the 
reliability and sequential consistency guarantees offered by AFIO far 
exceed those of Filesystem or STL iostreams.

Again, instead of jumping to conclusions based on ranting by a person 
with a well known personal vendetta against me, I'd suggest go read 
the documentation. If you come away with questions and concerns, ask 
them here. If you come away impressed, and I think you will be, all 
the better. If you come away thinking this library is deeply flawed 
and needs a substantial design refactoring, I am all ears because I 
would really love to know what's wrong with the AFIO API design *now* 
not later. That's why I am here, for a review of AFIO's design by my 
peers.

> Am I to understand that by design, AFIO's
> implementation implies lower performance than an alternative? (even if
> that alternative is something like libuv, which has its own flaws)

Current performance benchmarks can be found throughout the 
documentation, specifically the tutorials, the release notes and the 
reference documentation.

Is it lower performance than alternatives? Almost certainly, and the 
documentation takes pains to present AFIO in a worst possible light 
in any comparative benchmarks presented so nobody is under any 
illusions. What matters is correctness, reliability, reusability and 
portability - and most importantly of all - do NOT lose other 
people's data. As the tutorial shows, AFIO makes writing portable 
race free ACID safe file system code far easier than before, and 
there is your win case.

And for reference, AFIO v1.3's internal dispatch engine is over 20x 
faster than v1.0 was. I am always working on internal implementation 
performance improvements as I identify problems and I figure out 
solutions, same as any other Boost library author here.

Niall

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