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
> >> 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
> 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
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.
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk