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 17:32:55

On Thu, Aug 2, 2018 at 8:24 AM, james <dirtydroog_at_[hidden]> wrote:
> Networking is complex? Not necessarily so.

It is not the networking that is complex but rather, the asynchronous
model. In order to program it effectively, authors must have a deep
understanding of the following:

* Associated executors and associated allocators
* Initiating function return type customization (i.e. async_result)
* 13.2.7 Requirements on asynchronous operations [async.reqmts.async]
* Implicit versus explicit strands

> ASIO is confusing and over-engineered

It could probably use better documentation but I disagree with being
over-engineered. Take away anything from Asio (and consequently,
Networking TS) and the result is less functionality for users.

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

You have it backwards; the asio_handler_invoke mechanism was the basis
of executors, and predates executors by many years. Executors TS is a
refinement of the original Asio mechanism for specifying the algorithm
used to invoke a function object.

> To be fair, it's probably easier to use libuv and put up with the loss of
> type safety.

That is an apples to oranges comparison. libuv is an implementation
while Networking TS is the specification of an implementation. There
are no independent implementations of libuv, because libuv is not a
standard. Furthermore libuv is written in C and therefore offers
little to nothing in terms of abstractions. While Networking TS offers
very powerful abstractions, such as:

* ConstBufferSequence, MutableBufferSequence, DynamicBuffer
* SyncReadStream, SyncWriteStream
* AsyncReadStream, AsyncWriteStream
* ...much more

The benefit of these abstractions is that authors can more precisely
describe and achieve their intent with respect to implementation.

> At least you'll be able to set timeouts properly.

Unlike libuv, Networking TS does not make odd choices on behalf of the
user. Important decisions such as how to allocate memory or how to
implement timeouts can be decided by the application. There are many
ways to implements timeouts, but libuv offers only one while Asio
gives you the tools to implement them in any fashion. For example here
is an asychronous stream wrapper which implements read timeouts
transparently, and does so very efficiently: It only uses a single
timer and a single thread:

<https://github.com/vinniefalco/beast/blob/65f08791d0d7310a1427ad5d2bdd913287643d0d/include/boost/beast/experimental/core/timed_socket.hpp>
<https://github.com/vinniefalco/beast/blob/65f08791d0d7310a1427ad5d2bdd913287643d0d/include/boost/beast/experimental/core/impl/timed_socket.ipp>
<https://github.com/vinniefalco/beast/blob/65f08791d0d7310a1427ad5d2bdd913287643d0d/include/boost/beast/experimental/core/detail/timed_socket_service.hpp>

Test:
<https://github.com/vinniefalco/beast/blob/65f08791d0d7310a1427ad5d2bdd913287643d0d/test/beast/experimental/timed_socket.cpp>

On Thu, Aug 2, 2018 at 9:14 AM, Richard Hodges via Boost-users
<boost-users_at_[hidden]> wrote:
> A proper service which
> hands off work to a another thread and then marshals results back to the
> initiating object's executor.

See above.

Thanks