Subject: Re: [boost] This AFIO review - a modest proposal
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-08-23 17:59:16
On 23 Aug 2015 at 15:05, Glen Fernandes wrote:
> On Sun, Aug 23, 2015, Niall Douglas wrote:
> > Is acceptance of AFIO into Boost going to be judged on technical
> > reasons, or politics, or "I don't understand the point of this
> > library?"
> Isn't "I don't understand the point of this library" a valid reason
> for rejection?
In itself, no I don't think so.
There are at least ten libraries in Boost I have no understanding of
the point of (mostly the Maths ones). They are beyond me.
Last year I didn't understand the point of Edward's Boost.VMD
library, and I still don't. But other people said they were using it
and it was useful to them. That's plenty good enough for me.
I think the same applies here. Most C++ programmers think they have
zero need for race free file system . So why bother with AFIO?
Most C++ programmers have no need to do asynchronous filesystem or
file i/o. So why bother with AFIO?
Very few programmers anywhere in the world have a need for file i/o
to follow POSIX atomicity guarantees so they can write lock free
filesystem code. Probably only a few thousand in the world. Anyone
not crazy would just take a lock file and make it easy on themselves.
It's a niche library, no doubt. Just as Boost.VMD or Boost.uBLAS.
There is a small minority who will see a need for using it at all.
Everybody else will be, at best, indifferent. At worst, confused.
: There is definitely quite a bit of interest in race free
filesystem at WG21. My talk on race free filesystem at CppCon looks
like it will be well attended given who is also speaking in the same
> This is where you may have compromised the review (in
> my opinion):
> - The documentation isn't very straightforward. To me, it feels like
> it is all over the place
There is a lot of rare and hard to find documentation on real world
filing system behaviour in there. It has taken me months to collate,
some of which was from walking through operating system kernel code.
It's absolutely invaluable to people writing code in this niche
field, I already get quite a bit of email from people who found the
information from google mostly with thanks and Paypal donations
typically $25 or more.
But from the perspective of a Boost library review, it's clutter and
non-essential and distracting. I'm kinda caught here - is the
documentation for Boost peer reviewers, or for the actual Boost
library end user? I decided on the latter. Maybe I was wrong.
> - The examples in the documentation (bar the first one) also aren't
> very straightforward
The very first one was STL iostreams, so no AFIO at all.
Can you explain what is not straightforward more precisely please?
> You have said some things which make people question whether they
> really even need AFIO:
> - On more than one occasion you claimed that nobody needs an
> asynchronous file I/O library (and synchronous I/O coupled with some
> concurrency facilities like threads are sufficient).
I think I said that I thought that nobody *here* needs AFIO. Most C++
programmers think that ostream << obj; is all you ever need, and they
are probably right until they run into performance problems or start
> - That one needs AFIO not for performance (which you've demonstrated
> that it doesn't offer) but for safety, reliability, etc. This
> alienates everyone who doesn't care about these things.
Most C++ programmers will never use std::atomic nor Boost.Atomic nor
do they care about atomics.
AFIO is essentially Boost.Atomic for the file system, right down to
acquire, release and seq_cst.
Does this analogy help?
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/