ASIO vs Beast DynamicBuffer use

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

ASIO vs Beast DynamicBuffer use

Boost - Users mailing list
Hi,

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
(https://www.boost.org/doc/libs/1_68_0/libs/beast/doc/html/beast/ref/boost__beast__websocket__stream/async_read.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?

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

Regards.
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: ASIO vs Beast DynamicBuffer use

Boost - Users mailing list
On Thu, Nov 1, 2018 at 7:26 AM Cristian Morales Vega via Boost-users
<[hidden email]> 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
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users