Re: [boost] [AFIO] Callback API

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 
Asio
>> sockets. Write ordering can be handled, not by batching operations
>> together, but rather calling the next write operation from the 
callback
>> 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 
it.

Thanks for the feedback Bjorn.

Niall

-- 
Currently unemployed and looking for work.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/