=====
Async is a set of C++ primitives that allows you efficient and rapid development in c++17 on Linux systems. The focus is mostly on backend development, data processing, etc.
- Dependency on abseil-cpp
- Dependency on Boost 1.71
- Uses ninja-build on top of cmake
- Built artifacts are docker-friendly.
- HTTP server implementation.
- Fibers library and fiber-friendly synchronization primitives.
I will gradually add explanations for the most crucial blocks in this library.
Helio has utilized Boost.Fiber until May 2023. After this period, the fibers functionality was integrated directly into Helio code. This transition involved adapting and reworking portions of the original Boost.Fiber code to align with Helio's coding conventions and architecture.
The design and implementation of Helio fibers draw significant inspiration from Boost.Fiber. Certain segments of the Boost.Fiber code were selectively adopted and modified for seamless incorporation into Helio. We extend our deepest gratitude and recognition to @olk and all the contributors of Boost.Fiber for their foundational work.
The decision to replicate and modify the original code was driven by the necessity for greater flexibility. Specifically, it was easier to evolve Helio's polling mechanism when we had full control over the fibers internal interfaces.
Helio fb2 library adopts similar non-intrusive, shared nothing design similarly to Boost.Fiber. However, helio's fb2 library is more opinionated and also provides full networking support for asynchronous multi-threaded execution. helio fibers allows injecting a custom dispatch policy "util::fb2::DispatchPolicy" directly into a dispatching fiber, while Boost.Fiber requires using a separate fiber to handle the I/O polling. In addition, Boost.Fiber inter-thread notification mechanism (aka remote ready queue) required locking while helio fibers use a lockless queue.
> sudo ./install-dependencies.sh
> ./blaze.sh -release
> cd build-opt && ninja -j4 echo_server
third_party folder is checked out under build directories.
Then, from 2 tabs run:
server> ./echo_server --logtostderr
client> ./echo_server --connect=localhost --n 100000 --c=4HTTP handler is implemented using Boost.Beast library. It's integrated with the io_uring-based ProactorPool.
Please see http_main.cc, for example. HTTP also provides support for backend monitoring (Varz status page) and for an extensible debugging interface. With monitoring C++ backend returns JSON object that is formatted inside status page in the browser. To check how it looks, please go to localhost:8080 while echo_server is running.
HttpListenerBase::SetAuthFunctorWithQuery accepts a callback with the signature
bool(std::string_view path, const http::QueryArgs& args, std::string_view username, std::string_view password). It runs before built-in and registered handlers. Return
false to reject a request with HTTP 401. The existing three-argument callback is
also supported via SetAuthFunctor. Passing an empty callback to either setter
disables authorization checks; SetAuthFunctor(nullptr) and SetAuthFunctor({})
remain supported.
Query arguments are parsed once and shared with the handler. They retain duplicate
parameters and are not URL-decoded; their string views must not outlive the callback.
For example, an application can deny /flagz requests containing a nonempty flag
parameter to prevent flag mutation while retaining flag listing. A flag parameter
without a value still attempts to write an empty value.
Every http-powered backend has integrated CPU profiling capabilities using gperf-tools and pprof Profiling can be triggered in prod using magic-url commands. Enabled profiling usually has a very minimal impact on CPU performance of the running backend.
Logging is based on Google's glog library. The library is very reliable, performant, and solid. It has many features that allow resilient backend development. Unfortunately, Google's version has some bugs, which I fixed (waiting for review...), so I use my own fork. Glog library gives me the ability to control the logging levels of a backend at run-time without restarting it.
ASYNC uses a googletest+gmock unit-test environment.
io/proc_reader.h provides ReadCpuInfo() for /proc/cpuinfo, ReadDmiInfo() for
whitespace-trimmed sysfs DMI attributes, and the existing process and memory
readers. CPU hypervisor status is explicitly unknown, absent, or present; an absent
flag does not prove that the machine is bare metal.
ReadCpuInfo() returns io::Result<CpuInfo>. ReadDmiInfo() retains each
attribute's io::Result, so callers can inspect missing or unreadable attributes
independently. Both readers accept an alternate path for mounted system trees.
util/cloud/platform_info.h provides util::cloud::PlatformInfo::Create() for
local cloud, hypervisor, and deployment classification, keeping these heuristics
out of the I/O layer. The result retains each source's io::Result alongside the
classification enums. Detection uses DMI, CPU flags, environment variables, and
runtime marker files, without contacting metadata services. A file-root prefix
can be passed to inspect a mounted system tree; environment markers still
describe the current process. Consumers map enums to application-specific labels.
Third_party packages have TRDP:: prefix in CMakeLists.txt. absl libraries have prefix
absl::....