Eight Ways to Handle Non-blocking Returns in Message-passing Programs: from C++98 via C++11 to C++20
Play Eight Ways to Handle Non-blocking Returns in Message-passing Programs: from C++98 via C++11 to C++20
Shared-Nothing approach of "sharing memory by communicating" (instead of "communicating by sharing memory") gets more and more traction in the development world; this is not to mention that message-passing Shared-Nothing architectures have always been a cornerstone of both game development and UI development. These days, more and more projects realize the inherent dangers of combining business logic and thread sync within the same piece of code - which leads to cognitive overload (pushing developers well over 7+-2 boundary) and results in poor developer productivity, poor program reliability, and very often - subpar performance. In addition, message-passing programs allow to achieve determinism easily, which in turn provides very significant benefits, including such beauties as production post-mortem analysis, replay-based regression testing, and low-latency fault tolerance. Within the realm of message-passing programs, the problem of processing non-void returns from non-blocking calls is a particularly ugly one. Over time, approaches to solving it have progressed from simple message-sending to OO-based callbacks, and further to the lambda pyramids and futures. Still, programming non-blocking calls is a Big Headache(tm). In this talk, we'll discuss _eight_ different ways of handling returns from non-blocking calls in the context of message-passing architectures (using event-driven architectures as an all-popular example of message-passing). We'll start with a simplistic message exchange, and will progress to void RPCs, OO-style callbacks, lambda pyramids, single-threaded futures, lambda-based "code builder", coroutines/fibers, and co_await. Last but not least, we'll try to compare these different ways-to-handle-non-blocking-returns from the practical point of view, as well as the ways these eight ways are related to current C++ standard proposals; in addition - I'll argue for two important things-to-keep-in-mind for standard writers and implementors.