On Thu, 2 Aug 2018 at 17:25, james via Boost-users <boost-users@lists.boost.org> wrote:


On Thu, Aug 2, 2018 at 2:44 PM, Vinnie Falco via Boost-users <boost-users@lists.boost.org> wrote:
On Thu, Jul 26, 2018 at 6:03 PM, Gavin Lambert via Boost-users
<boost-users@lists.boost.org> 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.

In my view, asio suffers from:

a) incredibly terse documentation (it needs a lot more human 'chat' about 'why we do it this way', 'how we got here' and 'what this is actually trying to achieve')

b) No documentation at all for writing your own services which execute handlers properly - it's easy to write services 'wrong' (i.e. they end up posting a call to a functor) but I've never managed to write a service which works correctly with asio::use_future or a coroutine - it's just too much work to unpick all the non-documented detail in Chris's incredible work! This is a terrible shame as in all other respects I consider ASIO to me a masterpiece.
 

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. 

Sadly true until someone documents how to write a service properly. And I don't mean a trivial one as in the boost examples. A proper service which hands off work to a another thread and then marshals results back to the initiating object's executor.
 
_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users