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

Subject: Re: [Boost-users] ASIO: custom service which works with spawn/yield
From: james (dirtydroog_at_[hidden])
Date: 2018-08-02 15:24:18

On Thu, Aug 2, 2018 at 2:44 PM, Vinnie Falco via Boost-users <
boost-users_at_[hidden]> wrote:

> 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."
>
>
Networking is complex? Not necessarily so.
ASIO is confusing and over-engineered, and I bet there's a lot of identical
boilerplate code out that has
"this works, don't touch it" comments.

Networking.TS has unfortunately tied itself to executors, there was no need
for that.

To be fair, it's probably easier to use libuv and put up with the loss of
type safety. At least you'll be
able to set timeouts properly.