Boost logo

Boost :

Subject: Re: [boost] [AFIO] Callback API
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-12-28 14:56:41

On 28 Dec 2013 at 12:12, Bjorn Reese wrote:

> > I'm struggling to see the merit in such an approach - it would be
> > incredibly verbose and complex to write even simple solutions,
> > because i/o on files is not like sockets, *especially* that you
> > almost never must strongly order i/o across a sequence of multiple
> > sockets, but that is a very common case with files e.g. during ACID.
> First, it follows a pattern that is familiar to Asio users. So rather
> than you being the only one who can write applications on top of Afio,


The current API design really is very easy to program against once
you get used to thinking about i/o in that way. I find it very
"natural" to write, though like with most C++ writing many more lines
of source usually equals better quality code. I do wish C++ weren't
like that, but there it is.

> you get a broader community who are already familiar with the callback
> approach.

Understood. And I did try during AFIO design review to replicate
ASIO's API identically, until I realised that wasn't wise, purely
because of improved familiarity with the user base, and besides libuv
uses ASIO style callbacks.

> Second, you can more easily combine it with Asio socket code to create
> compound services that mixes socket and file access. For instance, a
> peer-to-peer file distribution mechanism.

Can I clarify something so? Where you stated:

>> I am thinking about an API that uses handles that looks more like
>> sockets. Write ordering can be handled, not by batching operations
>> together, but rather calling the next write operation from the
>> of the previous operation (Asio-style.)

By "calling the next write operation", I'm thinking that you're
thinking that a kernel API ought to be issued right there and then
yes just like ASIO does?

> > As much as this sort of operation dependency graph based design works
> > well for its niche, I agree there is a swathe of code which ends up
> > looking like the find in files implementation, and for that hopefully
> > fibers will make look much more sane.
> I am not arguing against the current API. Instead, I am arguing for the
> addition of a more familiar Asio-style callback API. I have no trouble
> with a fiber-enchanced API (similar to Asio with coroutines.)

Oh sure. But we'll test your assumptions about how file i/o works in
practice first. If they're the same as mine, I think I'll come to
understand exactly what you're looking for, and then I can implement

Thanks for the feedback Bjorn.


Currently unemployed and looking for work.
Work Portfolio:

Boost list run by bdawes at, gregod at, cpdaniel at, john at