Cancellation in Beast/Asio and Better Compile Performance with Beast.Websocket This month I will be discussing two issues. One of interest to many people who come to us with questions on the Github Issue Tracker and the #beast channel of Cpplang Slack. Compile Times and Separation of Concerns A common complaint about Boost.Beast is that compilation units that use the websocket::stream template class often take a long time to compile, and that because websocket::stream is a template, this compilation overhead can become viral in an application. This is a valid complaint and we believe there are some reasonable tradeoffs we can make by refactoring the websocket stream to use fewer templates internally. Vinnie has started work to express the WebSocket’s intermediate completion handlers, buffer sequence and executor in terms of a polymorphic object. This would mean a few indirect jumps in the compiled code but would significantly reduce the number of internal template expansions. In the scheme of things, we don’t believe that the virtual function calls will materially affect runtime performance. The branch is here I will be continuing work in this area in the coming days. In the meantime, our general response is to suggest that users create a...

Reviewing the review The review period for Boost.JSON has come and gone, and we got some great feedback on the design of the library. Glancing over the results, it appears that the general mood was to accept the library. This doesn’t mean that there weren’t any problem areas – most notably the documentation, which often did contain the information people wanted, but it was difficult to find. Other points of contention were the use of a push parser as opposed to a pull parser, the use of double, uint64_t, and int64_t without allowing for users to change them, and the value conversion interface. Overall some very good points were made, and I’d like to thank everyone for participating in the review. Customizing the build I put a bit of work into improving our CI matrix, as it had several redundant configurations and did not test newer compiler versions (e.g. GCC 10, clang 11), nor did we have any 32-bit jobs. The most difficult thing about working on the build matrix is balancing how exhaustive it is with the turnaround time – sure, we could add 60 configurations that test x86, x86-64, and ARM on every major compiler version released since...

Boost.JSON Boost.JSON is officially scheduled for review! It starts on September 14th, so there isn’t much time left to finish up polishing the library – but it looks like we will make the deadline. Optimize, optimize, optimize Boost.JSON’s performance has significantly increased in the past month. The change to the parsing functions where we pass and return const char* instead of result (detailed in my last post) was merged, bringing large gains across the board. After this, my work on optimizing basic_parser was complete (for now…), save for a few more minor changes: The handler is stored as the first data member as opposed to passing a reference to each parse function. This means that the this pointer for basic_parser is the this pointer for the handler, which eliminates some register spills. The parser’s depth (i.e. nesting level of objects/arrays) is now tracked as max_depth - actual_depth, meaning that we don’t have to read max_depth from memory each time a structure is parsed. parse_string was split into two functions: parse_unescaped and parse_escaped. The former is much cheaper to call as it doesn’t have to store the string within a local buffer, and since unescaped strings are vastly more common in...

New Debugging Feature in Asio and Beast As covered previously, Boost 1.74 brought an implementation of the new unified executors model to Boost.Asio. Support for this is not the only thing that is new in Beast. Chris Kohlhoff recently submitted a PR to Beast’s repository demonstrating how to annotate source code with the BOOST_ASIO_HANDLER_LOCATION macro. I have since followed up and annotated all asynchronous operations in Beast this way. In a normal build, there is no effect (and zero extra code generation). However, defining the preprocessor macro BOOST_ASIO_ENABLE_HANDLER_TRACKING will cause these macros to generate code which will emit handler tracking log data to stdout in a very specific format. The output is designed to describe the flow of asynchronous events in a format suitable for generating a visualisation in linear terms. i.e. the asynchronous events are flattened and linked to show causality. Here is an example of the output: @asio|1597543084.233257|>33| @asio|1597543084.233273|33|deadline_timer@0x7fa6cac25218.cancel @asio|1597543084.233681|33^34|in 'basic_stream::async_write_some' (../../../../../../boost/beast/core/impl/basic_stream.hpp:321) @asio|1597543084.233681|33^34|called from 'async_write' (../../../../../../boost/asio/impl/write.hpp:331) @asio|1597543084.233681|33^34|called from 'ssl::stream<>::async_write_some' (../../../../../../boost/asio/ssl/detail/io.hpp:201) @asio|1597543084.233681|33^34|called from 'http::async_write_some' (../../../../../../boost/beast/http/impl/write.hpp:64) @asio|1597543084.233681|33^34|called from 'http::async_write' (../../../../../../boost/beast/http/impl/write.hpp:223) @asio|1597543084.233681|33^34|called from 'http::async_write(msg)' (../../../../../../boost/beast/http/impl/write.hpp:277) @asio|1597543084.233681|33*34|deadline_timer@0x7fa6cac25298.async_wait @asio|1597543084.233801|33^35|in 'basic_stream::async_write_some' (../../../../../../boost/beast/core/impl/basic_stream.hpp:373) @asio|1597543084.233801|33^35|called from 'async_write' (../../../../../../boost/asio/impl/write.hpp:331) @asio|1597543084.233801|33^35|called from 'ssl::stream<>::async_write_some' (../../../../../../boost/asio/ssl/detail/io.hpp:201) @asio|1597543084.233801|33^35|called from 'http::async_write_some' (../../../../../../boost/beast/http/impl/write.hpp:64) @asio|1597543084.233801|33^35|called from 'http::async_write' (../../../../../../boost/beast/http/impl/write.hpp:223) @asio|1597543084.233801|33^35|called from 'http::async_write(msg)' (../../../../../../boost/beast/http/impl/write.hpp:277) @asio|1597543084.233801|33*35|socket@0x7fa6cac251c8.async_send @asio|1597543084.233910|.35|non_blocking_send,ec=system:0,bytes_transferred=103...

Boost 1.74 - Progress Update Boost 1.74 beta release has been published and the various maintainers are applying last-minute bug fixes to their libraries in readiness for the final release on 12th August. For us in the Beast team, a fair amount of attention has been spent monitoring last minutes changes to Asio, as Chris makes the final tweaks after the Unified Executors update I mentioned in last month’s blog. Comprehensive Testing Last month I committed what I hoped would be the first of a suite of Dockerfiles which help the mass testing of Beast. The upstream changes to Asio were a lesson in just how many compilers, hosts and target environments we have to support in order that our user base is not surprised or impeded as a result of compiler selection or imposition. I am not expert is Docker matters. I mean, I can read the manual and follow basic instructions like anyone else, but I was hoping that someone would come along to help flesh out the suite a little. Particularly for the Windows builds, since I have no experience in installing software from the command line in Windows, and the greatest respect for those individuals who...