Hi all,
This is my review of boost.afio. In fact I have still more comments on
the library, but this is taking already too long and I'm well past the
review deadline, so I'm sending what I have. I'm hopefully going to
post the second part in the next few days.
1. Should Boost.AFIO be accepted into Boost? Please state all
conditions for acceptance explicitly.
No, not at this time. While the library is potentially quite useful,
possibly to larger niche than expected to the author, I have many
issues with both the documentation and the API itself, which would
need to be resolved before acceptance.
To be clear, this is not a conditional acceptance. I believe a full
review is warranted to verify that the issues have been addressed.
The author is obviously quite experienced in this area (or at least
has done a lot of research), so I strongly encourage him to resubmit
the library in the future as it has the potential to be be a great
contribution to boost.
2. What is your evaluation of the design?
My preference, but wouldn't require for acceptance, would be to use ASIO async
protocol that leaves the choice of the completion notification
strategy to the user .
If the library wants all async functions to return futures, it should
follow the standard future idioms. First of all, having futures which
claim 'standard conformance' and then carry extra hidden error payload
is unacceptable. Also functions should take handlers as parameters and
not futures. The user should be responsible of explicitly 'then'
chaining futures. The library should follow the standard semantics for
handle types (i.e. single ownership move only wrappers system
handles), and similarly for the future wrappers for such handles
(i.e. future<handle>, not shared_future<handle>). Other reviewers have
discussed these issues better than I could, so I won't expand further.
The dispatcher should probably be called filesystem because that's what
it is.
The overridable per thread global dispatcher is evil. Functions should
take a dispatcher explicitly (or through a handle_ptr) or use a static
global dispatcher that represent the global filesystem.
Does the library need to distinguish between files and symlinks at
open time by calling differently named functions? I'll assume that's
the case, but I would like to know the rationale.
File, directory, symlink functions should be verbs and called
open_file, open_directory, open_symlink. They should return
differently typed handles (i.e. file_handle, dir_handle, sym_handle).
As an aside, the handle types should have value semantics and be movable.
To help generic code, rmdir, rmfile and rmsymbol should be unified
under the same function name (rm, or better delete). The parameter
type can be used to select the correct overload.
Functions that return handles must do so explicitly (i.e. no implicit
handle payload).
The library should *never* cause the program to crash because of
external causes (i.e. files and dirs disappearing or truncated,
external locks taken, lock forcibly removed, up to and including disk
failure). It is ok to abort on a failed internal consistency check,
although it would be nice if the check+abort was encapsulated in an
overridable macro (BOOST_AFIO_ASSERT maybe?). It is fine and even
encouraged for the check be present even in release builds.
The library *must* not suppose that every other program interacting
with the filesystem is using AFIO. It is fine if the library were to
give some additional guarantees (for example advisory locking becomes
non-advisory), but these guarantees should be properly documented.
For example, writes in append should be guaranteed atomic no matter
what the program doing the writes is doing. In practice, this means
that afio should document in detail the implementation of each
operation for each backend for each operation so that a knowledgeable
user can make the necessary inferences. In practice this seems already
to be mostly the case.
The documentation has a huge amount of notes on how the various FS and
OSs differ and what are the different guarantees. AFIO should provide
a standardised set of flags describing the various capabilities and a
query interface, so that the inevitable different code paths do not
need to be fs name dependent or, worse, #ifdef based. A good starting
point for deciding which flags to expose, are the various FS tables
scattered through the docs.
3. What is your evaluation of the implementation?
I haven't had a chance to do an as in depth evaluation. Additionally,
files with thousands of lines do not make it easy to read the
code. The git repo contains both v1 and v2 subdirectories, and I'm not
sure which one is the one actually under review (the docs say 1.5, not
sure which one it is)'
A few comments:
Overuse of shared_ptr is in my experience code smell as the unclear
ownership semantics lead to bugs down the line.
The amount of ifdefs is staggering. Most of them are probably
necessary, but the number of options that the library can be
configured with certainly doesn't help.'
It depends on external non-boost libraries, which it seems (but I
can't be sure because of the layer of versioning macros) inject names
outside the boost::afio namespace, which it shouldn't happen.
With two spinlock acquisition per move, the lightweight future/modand
seems anything but lightweight.
The library should really use boost::future instead of rolling its
own. The author should attempt to fold possible improvements directly
into boost.thread.
Similarly for any necessary improvements to Boost.Asio (for the WoW
issue) and Boost.Filesysterm (for boost::path).
The abstraction overhead seems excessive, especially for a library
suposedly IO bound. The author should at least try to mach the
performance of the naive openmp implementation.
BTW, nonvolatile ram based storage will be becoming mainstream within the
year, so the author might need to revisit very soon the relative cost
of various operations.
Random suggestions (feel free to ignore these):
- look into non temporal stores to help with cache pollution.
- have a libnfs backend + NFS over loopback for truly asynchronous
filesystem operations (performance is probably going to atrocious).
- experiment with the "O_NONBLOCK disk read" patches for the linux kernel.
4. What is your evaluation of the documentation?
As noted by others, the documentation does not seem to be of boost
standard quality; At times it feels more like a stream of
consciousness; often irrelevant or less important information is
presented before more important ones.
Disquss Comments do not belong in the documentation.
With JS disabled, some pictures are not shown, at least in the single page docs.
I'm less bothered than others about the 'try AFIO online button'. In
fact it would be nice to have such a button after each example (I'm
not suggesting that the author should provide it though).
Any reference to not-implemented features should removed and at best
moved to a separate section at the end of the documentation. A common
patters is:
"" AFIO implements
* A
* B (not implemented)
* C (not implemented)
* D (not implemented)""
which is, honestly, a bit ridiculous.
Similarly scattering references to preivious versions of the library
all over the documentation is confusing. These should go to a separate
history page and/or changelog.
The misuse of Terms of Art ('monad' 'precondition') seem
a bit worrying.
At every occurrence of the term 'filing system' my brain trips. For a
while I thought it meant something subtly different from the more
common 'filesystem' or 'file system'. This could be just me, so feel
free to ignore this unless others complain.
The documentation often references C++1z coroutines, which as far as I
understand are far from being standardisation ready. It would be
better if examples using boost.coroutine, boost.context or even
asio.coroutine were provided.
** Intro
The first paragraph is a nice introduction, but it should mention
prominently that AFIO helps prevents file system races.
Move the sub points of bullet 8 to top level, instead deemphatize and
sythetize the performance claims under a single bullet. Before
claiming performance, describle what the library can do.
Reduce any reference to APIBind to a single line (something 'AFIO can
be used as a standalone library thanks to APIBind', details elsewhere;
also do not claim that APIBind is a boost library). Remove any
references to backends from this section. Totaly remove references to
unimplemented backands. Supported compilers and platforms, jenkins and
uni tests etc do not belong here. Neither do links to dispatch
benchmarks.
You might want to mention that it is a C++11 library written as part
of the GSoC. A reference to ASIO might or might not belong here (No
ASIO class or concept seem to be part of the interface).
Remove the Batch section from the simple example. Also the rest should stand
by itself, without the comments.
About the example itself: I find it surprising that you call the
results using verbs and operations using names. A better naming
convention would be nice.
Also in general please prefer
type result = op(params);
to
type result(op(params));
at least when op is an important operation. The initialisation syntax
together with the noun based naming convention makes it harder to
parse examples.
** Cheat Sheet
The frist few paragraphs are interesting, but should go after the
table. The table as is not useful, other than an alternate index. I
would expecte something like; function name, paramenters, result, very
short description. I have no idea what the other columns of the table
are trying to convey. The related functionality at the end does not
belong here.
** Design Introduction and Rationale
In this page I would expect to find an analysis of a generic afio
async operation, why a certain interface was chosen, how futures help
compose operation, how an operation is implemented internally. For
every choice a discussion of the design tradeoff should be presented.
Unfortunately, after an interesting "why did I write this library",
the chapter loses itself. The version history does not belong here
unless is used to justify design choices, but other than saying that
previous versions where slower, no other information is conveyed.
In particular, at this point of the documentation I would expect a
thorough explanation of the concept of a FS race and the minimum
guarantees given by the library with respect to file system races.
Additionally as the library comes with its own future implementation,
a detailed explanations of why boost::futures is not sufficient should
be given.
As an aside, the author claims that the library is completely lock
free, and it would be wait free if not for the the use of
spinlocks. This does not makes any sense as the use of spinlocks also
make the library *not* lock free, unless the author is using a
non-standard meaning for these terms (again see previous comment about
misuse of Terms of Art).
** Write Ordering Constraint
The explanation on how sync behaves like a barrier and the description
of scheduling ordering and dependencies is very useful, and it should
be a great starting point for a formal treatment of race freedom.
The description of TripleGit is completely unnecessary and should be
removed.
** Compilation
This section is very confusing. Let' say I want the default (whatever
it is) and do not define anything. I get this:
After defining your build macros of choice, making latest AFIO
available to your code is as simple as:
#include "boost.afio/include/boost/afio.hpp" // latest version
#include "boost.afio/include/boost/v1/afio.hpp" // specific version
if being used standalone or if being used as part of Boost:
#include "boost/afio.hpp" // latest version
#include "boost/afio/v1/afio.hpp" // specific version
I have no idea what any of the above means.
** Boost AFIO Installation into Boost
Why is this information not part of the previous chapter? Any
reference to non boost.afio should be dropped (except possibly to a
link at the end to an external non boost distribution).
I understand the the external build instructions are useful for
reviewers, but they shouldn't have been part of the documentation
under review.
** Supported compilers
not much to say here other than, assuming AFIO is accepted, the table
would be static and reflect the specific released version instead of trunk.
** Example 1
All references to the macro based versioning should be dropped.
I have no idea why the example datastore has to return a
monad<shared_ptr<iostream> >.
The shared pointer is gratuitous, and for the ""simplest interface"
errors can be communicated by exceptions
As defined I would expect an interface like this for the simplest store:
optional<std::string> read(std::string key)
void write(std::string key, std::string content)
or something like this for something more complex:
some_special_container_range read(std::string key)
template<class Range>
void write(std::string& key, const Range& range);
Possibly the author has in mind something different than a key value system.
** Example 2
Because the interface is non-ideal, it is hard to evaluate the next
examples.
Freedom from directory renames in nice, but I wouldn't count it very
high in the list of requirements for an object store.
A dispatcher is introduced, without explanation of what it is. The
cheat-sheet mentioned it, but it should be described in more details here.
The VM shenigans required to make something like
utils::file_buffer_allocator<> work can have serious and hard to
pinpoint performance and scalability considerations and shouldn't be
presented as a performance win uncritically. The tradeoffs should be
discussed.
Also read mappings can defeat the point of async IO as the application
threads will be subject to blocking page faults.
Both previous comments are not trying to suggest that mmap is not
useful, but it shouldn't be treated as a transparent optimisation as
it can have application wide consequences well outside IO code. As far
as I understand boost.afio leaves the choice to the client code and
never does mmap behind its back; still the examples should present
best practices.
The example is too long and has too many distractions. The
demonstration a streambuf can be implemented on top of afio is quite
interesting, but should be relegated to a separate example.
** Example 3
BOOST_MONAD_PROPAGATE, in addition to being in the wrong
namespace, is not documented anywhere (at least a search in the one
page doc does not lead anywhere) and seems completely unnecessary. I
guess it expands to either a return or a throw.
In 'The problems with this naive design', the table does not have unit
of measure. The information is interesting, although, without any
comparison of durability, concurrency and atomicity guarantees of any
of the solution, is hard to infer anything (not that I expect much
from a NoSQL db...).
** Example 4
' Linux is different from other operating systems in that you must
explicitly request metadata updates to be sent to physical storage'
I'm not an expert, but I thought this was true only for ext3/4 (and
only with some, albeit default, mount options) and generally
considered broken even by Linus himself. If that's the case might be
important to point it out so users can choose other FSs.
The atomic key replacement example is nice. Should the library
provide pre-made recipes for these kind of uses?
In The FS table, the first few column titles should be reworded so
that all checkmarks mean that a positive feature is available and 'x'es
mean a lack of it.
'This is a good example of where Intel's Hyperthreading can really
penalise overall performance sometimes: filing systems tend to
parallelise linearly to real CPU core count only.'
Why is that the case? I would expect the exact opposite in fact. Are
you sure the performance bottleneck is not somewhere else (TLB
invalidation, cache misses, badly sized hash lock pools)?
** Example 5
The extent based and append behaviour are great.
'Any writes we make within a 4Kb boundary is probably safe'. 'Probably
safe' is not something I want to see when implementing a DB.
The example is probably way too complex for a tutorial, also the fact
that is incomplete makes it hard to evaluate.
** Hello World
Please remove the long comments from the examples. Either make them
part of the surrounding explanation or footnotes.
** A less toy example
The documentation sometimes claims that AFIO is either faster than
dumb stream based IO and sometimes assert that it is slower. Please
pick one and stick to it. Or better, do not make any performance
claims outside a benchmark page. Performance should not be the biggest
claim for AFIO anyway.
The example uses stl_future which is not defined anywhere in the
documentation as far as I can see.
when_all_p(ihs).get();
should probably be when_all_p(ihs_req).get()
In general, unless I've completely misunderstood the example, all the
.get() calls impose synchronisation, which means that the
parallel_concatenate is not as asynchronous as possible. Also it
should really schedule handle closes at the end and return a
future<void>.
for(auto &i : ihs)
lasts.push_back(dispatcher->depends(ohresize, i));
The meaning of dispatcher->depend on this code is not obvious at
all. From mailing list discussions I assume that depend(future a,
bufure b) is a.then([b] { return b; }), but what's the role of the
dispatcher here is opaque. Even more surprisingly, a few lines below
depend is called as a free function.
Also, a few lines above this line is present:
when_all_p(ohresize).get();
which should impose an explicit synchronisation, making the depend
superfluous.
This is the implementation I would like to see:
using br = boost::range;
auto async_size = [](auto&& name) {
return async_info(name).then(auto&& info) { return info.size(); };
};
auto open =[](auto&& name) { reutrn asyn_open(name); };
auto get = [](auto&& future) { return future.get(); };
auto always = [](auto&& x) { return [x=std::move(x)] { return x;}; };
auto unwrap = [](auto&& fr) {
std::vector<typename decltype(fr)::value_type> ret;
copy_to(ret, mapped(fr, get));
return ret;
}
template<class PathRange>
std::future<std::size> asyn_concat(std::path destname, PathRange&& srcnames)
{
auto sizes =
when_all(br::mapped(srcnames, async_size))
.then(unwrap)).share();
auto total_size = sizes
.then([](auto&& range) {
return br::accumulate(range.get(), 0);;
});
auto srcs_range = when_all(br::mapped(srcnames, open));
auto dest = when_all(async_open(destname), total_size)
.then([](auto fdest, auto size )
[] {
auto dest = fdest.get();
return async_truncate(dest, size).then(always(dest));
});
return wait_all(srcs_range, dest, fbuffers)
.then([](auto&& fsrcs, auto && fdest, auto&& fsizes) {
auto&& sizes = fsizes.get();
std::vector<handles> srcs = unwrap(fsrcs);
std::vector<std::future<> > writes;
struct ctx {
off_t offset = 0;
ssize_t len = 0;
std::vector<char> buf = std::vector<char>(1024*4);
};
std::vector<ctx> ctxs;
ctx.reserve(src.size());
std::size_t off = 0;
auto dest = make_unique(fdest.get());
for(int i = 0; i != src.size(); ++i)
{
ctxs.push_back({ off, sizes[i] );
off += sizes[i];
auto& ctx = ctxs.back();
auto read = [&ctx, &s = srcs[i]] {
if (ctx.len < ctx.buffer.size())
ctx.buffer.resize(ctx.len);
ctx.len -= ctx.buffer.size();
return async_read(s, ctx.buffer);
};
auto write = [&ctx, &dst = dest.get()] {
auto off = ctx.off;
ctx.off += ctx.buffer.size();
return async_write(s, off, ctx.buffer);
};
auto read_write = [&ctx, read, write](auto self){
if(ctx.len)
return read().then(write).then(self);
return make_ready_future();
};
writes.push_back(read_write(read_write));
}
return wait_all(writes).then(
[ctx=std::move(ctx), dst=std::move(dst), src=std::move(src)]
{
return wait_all(
mapped(srd, [](auto&& s) { return async_close(s); })
.then([d = async_close(dst)] { return d; }))
});
});
};
Note that everything is perfectly parallel and dependencies are
minimal. Most operations use unique semantics except for 'sizes' where
I didn't bother to do better. The lifetimes of buffers and handles in
the read/writes are admittedly subtle, but not too much. Instead of
creating N futures per file, I'm creating just a single one at a time.
** (all examples)
Overall the examples are nice, the progression of additional
features makes sense. The code should be cleaned up to remove
superflous code. Comments should be removed and the code should be
discussed in the prose (possibly referencing line numbers). I suggest
that the strawman interface using iostream is removed. The lookups
should simply return initially optional<string>, then future<string>.
future<string> (or future<vector<char> >) of course does not work well
for large buffers. You could return something like future<chunk>,
where chunk has the following interface:
struct chunk {
const char * begin();
const char * end();
std::size_t size(); // an empty chunk means we are done
future<chunk> next(); // invalidates this
};
but the reality is that futures are not great for lazy streams. You
could look into reactive streams, but that's another can of worms. For
pure read/writes I suggest an asio-like interface which uses callbacks
would be optimal and readily familiar to boost users.
5. What is your evaluation of the potential usefulness of the library?
I had never had a chance to look at the library in the past, and my
only impressions of it came by the many references and claims made by
the author in the boost mailing list. In particular I was baffled by
the author's claim that the ASIO callback interface is not adequate
for file IO. I could not understand how async read/writes from a file
could be so significantly different from socket io.
Turns out that the actual I/O part is just a small part of the
library, and the async part even less. The bulk of the library is
about writing roboust filesystem manipulations. In my mind, where
boost.filesystem is designed as a simple interface to file system
operations for script-like programs, AFIO attempts to be the goto
interface for robust applications.
6. Did you try to use the library? With what compiler? Did you have
any problems?
I didn't trey to compile or use the library.
7. How much effort did you put into your evaluation? A glance? A quick
reading? In-depth study?
An in depth study of the documentation. I didn't keep track of the
hours, probably 10 or more.
8. Are you knowledgeable about the problem domain?
Asynchronous File IO? No. Race free file IO? Neither, but had to deal
with these kind of issues in the past. Something like AFIO might have
been useful.
