[boost] Universal async in C++ (was: Re: [Fibers] Performance)

Subject: [boost] Universal async in C++ (was: Re: [Fibers] Performance)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-01-21 13:20:27

On 21 Jan 2014 at 10:09, Nat Goodspeed wrote:

> >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3747.pdf
> 
> > That's a good paper, but I wish it didn't claim to be a *universal*
> > model for asynchronous operations because that model is completely
> > unsuitable for persistent storage i/o. I had that argument with
> > Nicholas @ Microsoft Research actually, and I think I may well have
> > persuaded him as they're seeing the same problems of fit.
> 
> Niall, would you be able to propose a more universal model? Please
> read this as a simple invitation rather than a challenge. The goal of
> the paper seems laudable: accepting an argument that allows the caller
> to specify whether to provide results with a callback, a future or
> suspend-and-resume.

I think I effectively have via AFIO which uses an asynchronous 
execution precedence graph model with explicit gathering for error 
propagation, which unlike the proposed model works as well with 
seekable i/o as fifo i/o. The problem with the AFIO model though is 
that it is very heavily reliant on the performance of futures (and 
therefore the memory allocator) as those are used to transport state 
between closures, and for those with very low latency very small 
packet (e.g. UDP) socket i/o it's unsuitable (which is of course 
pointed out in the WG21 paper). My opinion there is that callbacks 
can become a low level interface for those who need it, while the 
execution precedence graph model is much easier to program against 
for everything else.

You're probably about to ask me for a N-paper, so I'll save an email 
cycle by explaining my hesitation on that. Bjorn Reece has been 
working extensively with me off list to de-wart AFIO when combined 
with ASIO such that async socket and async disc i/o seamlessly 
interoperate, specifically he's persuaded me to supply async_io_op to 
completion handlers which is going to be a technical challenge for me 
to implement in a safe and quick way, but I think I am capable though 
it's going to hurt. I will start that work item once I clear my maths 
coursework (hopefully tomorrow), and file my consulting company's 
annual accounts (hopefully end of this week). Also, I might actually 
have a job interview soon, which amazes me as I had expected at least 
three months to elapse before any jobs in C++ turned up (there are 
about six a year total in this region).

Both Artur and Niklas who are leading out Microsoft's work on async 
in C++ are aware of AFIO's design approach, and last time I heard 
they found themselves coming ever closer to AFIO's design as they 
find blocking issues and corner cases in their proposals. I think it 
will be more productive for now for me to keep nagging them on their 
N-papers rather than write one of my own. After all, being in Europe 
and being unemployed makes it extremely tough to attend C++ standards 
meetings, and I don't personally rate a N paper's chances if someone 
isn't at the meetings to champion it i.e. present in the bar 
afterwards to argue merits with people.

Hopefully this explains things. Do point out any problems in my 
thoughts.

Niall

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