Re: [Boost-users] ASIO: custom service which works with spawn/yield

Subject: Re: [Boost-users] ASIO: custom service which works with spawn/yield
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2018-08-02 13:44:02

On Thu, Jul 26, 2018 at 6:03 PM, Gavin Lambert via Boost-users
<boost-users_at_[hidden]> wrote:
> This raises a concern that I've had for a while; if it's this hard to
> implement asynchronous operations correctly, I can't see it being very
> successful in practice.
> ...
> This means that everybody, including general application developers, needs
> to be able to easily write asynchronous methods, without having to worry
> about falling into these pitfalls.  (It needs to be a "pit of success", not
> requiring several code reviews by experienced library developers in order to
> spot the mistakes.)

I feel you. But I do not see any obvious improvements or alternatives
to the current design of [networking.ts], which provide the same or
greater levels of expressive power and performance. There is nothing
"easy" about writing concurrent asynchronous code in C++, which I
believe is a consequence of having zero-cost abstractions. The
following is an excerpt from a recent paper of mine:

"From the author's experience and the visible cascade of problems with
the example code in this paper, writing initiating functions and
composed operations correctly requires a demanding amount of
experience and skill. This is especially true when considering that
such algorithms must also implicitly exhibit correct behavior in
multi-threaded environments. This is accomplished by achieving a deep
and thorough understanding of Asio or [networking.ts] and applying
that understanding to code. The author and contributors to Boost.Beast
have explored library solutions to provide some correct boilerplate
and higher level idioms to users in order to make authoring composed
operations easier to write. A little bit of progress has been made on
this front, but comprehensive improvements have been elusive. We
suspect that grand unifying solutions simply do not exist, and that
the level of complexity is inherent to the domain."

Regards