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

Subject: Re: [Boost-users] ASIO: custom service which works with spawn/yield
From: Richard Hodges (hodges.r_at_[hidden])
Date: 2018-08-02 16:14:53

On Thu, 2 Aug 2018 at 17:25, james via Boost-users <
boost-users_at_[hidden]> wrote:

>
>
> 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.
>

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_at_[hidden]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users
>