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_re...) Beast passes them via reference (https://www.boost.org/doc/libs/1_68_0/libs/beast/doc/html/beast/ref/boost__b...). 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.
On Thu, Nov 1, 2018 at 7:26 AM Cristian Morales Vega via Boost-users
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_re...) 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
On Thu, 1 Nov 2018 at 15:02, Vinnie Falco via Boost-users
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:
Not sure how the whole C++ committee thing works. But I was wondering if anything about this came out from San Diego.
On Wed, Jan 2, 2019 at 1:32 PM Cristian Morales Vega
Not sure how the whole C++ committee thing works. But I was wondering if anything about this came out from San Diego.
Since Networking TS was pushed to 2023, there is no longer urgent need to review related papers. This paper will be taken up in LEWGI on the lib-ext reflector any day now... Regards
participants (2)
-
Cristian Morales Vega -
Vinnie Falco