Boost logo

Boost :

Subject: Re: [boost] [afio] Formal review of Boost.AFIO
From: Gruenke,Matt (mgruenke_at_[hidden])
Date: 2015-08-30 19:05:41


This obviously isn't a proper review, and shouldn't be counted as such. Rather, I pose a question to other reviewers: for how many of you does this actually solve a problem you've faced or anticipate? For me, the answer is "no". Otherwise, I'd invest further time in a proper review.

The reason I ask is that I've dabbled a bit in async file I/O, in the context of media streaming. At the time, what I needed was simply a portable abstraction over whatever the kernel provides in the way of non-blocking file I/O. I didn't need at least 95% of what AFIO does, and the one thing I did need is not implemented. From the docs:

> Boost.AFIO provides a pure portable POSIX file i/o backend and specialised file
> i/o backends making use of host OS asynchronous file i/o facilities are provided for:
...
> * Linux KAIO (planned, would reduce thread pool blocking for read() and write() only)
> * POSIX AIO, suitable for BSD only (planned, would reduce thread pool blocking for
> read() and write() only)

This leaves me feeling that it's a solution that's searching for a problem. I think Niall has done great work on it, from the little I've seen. But if I want a fast, disk-based database, I'll use sqlite - which does a lot more for me - not go straight to the filesystem. As for single-file I/O, I don't want to second-guess the kernel (though maybe having a threaded backend, as a fallback that users could explicitly select, would be helpful).

So, I'm not going to weigh in on its inclusion, because I honestly don't know how useful it'd be. If others think it is, then I doubt there's a better implementation of that functionality to be found.

What I saw of docs looked good, and I was glad to see benchmarks. More generally, I also appreciate Niall's participation in the boost (and ASIO) community.

Matt

________________________________

This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk