Re: [boost] This AFIO review - a modest proposal

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 [1]. 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.

[1]: 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 
time slot.

> 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 
losing data.

> - 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?

Niall

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