Re: [Boost-users] ASIO vs Beast DynamicBuffer use

Subject: Re: [Boost-users] ASIO vs Beast DynamicBuffer use
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2018-11-01 15:01:22

On Thu, Nov 1, 2018 at 7:26 AM Cristian Morales Vega via Boost-users
<boost-users_at_[hidden]> wrote:
> I have just noticed that while ASIO passes DynamicBuffers as &&
> (https://www.boost.org/doc/libs/1_68_0/doc/html/boost_asio/reference/async_read_until/overload2.html)
> Beast passes them via reference

Yes you are correct. I kind of independently "invented" the
DynamicBuffer concept, modeling it after boost::asio::basic_streambuf,
before I saw it in the Networking TS. And when I read the TS, I
totally did not notice that the concept had different semantics,
because the requirements didn't make it clear. The only clue was that
dynamic buffers needed to be MoveConstructible, which seemed odd but
most of beast's are also move constructible so I didn't think anything
of it.

Then when net-ts flavored asio was merged into Boost, I saw what
happened. There's a problem with the net-ts model of dynamic buffers
acting as a reference instead of a true storage type, which I have
detailed in this paper that I will present in San Diego this month:

<http://vinniefalco.github.io/papers/p1100r0.html>

> I'm guessing this happens because ASIO thinks you are going to use
> dynamic_string_buffer/dynamic_vector_buffer as DynamicBuffer, while
> Beast thinks you are going to use flat_buffer/multi_buffer. In the
> second case doesn't make sense to give ownership of the DynamicBuffer
> to the initiation function because then you would not be able to look
> at the received data when the operation completes. Since ASIO
> DynamicBuffer implementations are just adaptors over string/vectors
> that you keep, it makes sense to move those adaptors, you still keep
> the string/vector with the data. Have I got it right?

Yes you have it exactly right. But the situation is even worse due to
the issues I raised in the paper linked above.

> But this raises the question: what should I use in my own initiating functions?

Well, that's a good question. If you follow the net-ts semantics then
your initiating functions can't be composed into higher-order composed
operations which also operate on a dynamic buffer. At least, not
without doing some really ugly stuff that includes extra memory
allocations.

My position is that we should roll back the concept to work the way
that basic_streambuf works. Treat dynamic buffers as true storage
types.

Hope this helps!

Vinnie