redboltz
commented
5 years ago I don't believe that this is possible. boost::asio tcp sockets are "streams" of data. So if any new data arrives before we've finished reading from the stream, the data that has arrived will be en-queued to the back of the queue. The data that we are currently reading will stay in place.
Nice comment and nice timing! I can save a lot of time :)
I had forgotten I call the next async_read() after all io_service::post() sequences are finished.
So interleaves are never happen.
I choose approach 2. Thank you!
This is related to https://github.com/redboltz/mqtt_cpp/issues/248, https://github.com/redboltz/mqtt_cpp/issues/191, and https://github.com/redboltz/mqtt_cpp/issues/289
I was working more with the v5 properties, and realized that when we receive the properties from the network we allocate a new buffer for the std::vector<> to store the mqtt::v5::property_varients, even if the property_varient only holds ref properties.
I'd like to see mqtt_cpp support zero allocations for handling the data from incoming packets.
We can do that with the following changes:
1) Store a pool of shared_ptr<char[]>, which each message is written into. 2) All callbacks that endpoint.hpp calls when passing messages up to the user level code pass "ref" objects, such as mqtt::string_view, mqtt::will_ref, mqtt::property_ref 3) The callbacks also pass an mqtt::any, which holds the shared_ptr<char[]> for the message that all of the ref objects refer to.
A more complicated, but "better" way to handle this is to:
1) Store a pool of shared_ptr<char[]>, which each divisible part of a message is written into. 2) This means that each message contents, username, password, v5::property, and so on are written into their own buffer. We'll need to have each buffer be contiguous so that higher level classes like string_view and stuff can refer to them directly, but we should be able to keep memory fragmentation down by setting a minimum buffer size of e.g. 256, and always retrieve buffers as multiples of twos. 3) All callbacks that endpoint.hpp calls when passing messages up to the user level code pass "ref" objects, such as mqtt::string_view, mqtt::will_ref, mqtt::properties. 4) Create some kind of mqtt::owning_string_view that implements the API from mqtt::string_view, but also holds a handle to the std::shared_ptr<char[]> 5) Modify mqtt::will and mqtt::property to always hold a reference to the std::shared_ptr<char[]>, and when they are created by user code, serialize directly into a newly allocated std::shared_ptr<char[]>. 6) Each of the callbacks that endpoint.hpp calls don't need to be modified because each of the arguments already holds a std::shared_ptr<char[]>.
Further, for the above handling of properties we have two ways to avoid allocating that std::vector.
We can either have std::vector<> pull it's storage from the same memory pool of char[]'s, or we can create a new custom data type "property_cursor" that has a pointer to the entire message, and iterates over the message on an as-needed basis to construct the property objects on the fly.
If we implement this by having each chunk of the message given to it's own buffer (more complicated, but would be better over all in my opinion), then we should have the std::vector<> use the memory pool as an allocator.
If we have each message stored in a single buffer, we should implement this using the "property_cursor" concept.
@redboltz I'd like to hear your thoughts on the matter.