SObjectizer: actor, pub/sub and CSP models in one C++17 framework

What SObjectizer solves, and who it is for

SObjectizer targets concurrent computing: doing many different things at once, with agents exchanging asynchronous messages. The README draws a hard line between that and parallel computing, where the goal is to cut the wall-clock time of one computation by spreading it over several cores. The project's own examples of suitable applications are a multithreaded proxy server, an automatic control system, an MQ broker and a database server. If you are writing a video encoder or a numerical kernel, the README states directly that comparing SObjectizer with TBB, taskflow or HPX is useless, because those tools serve a different area. The intended user is a C++ developer who wants message dispatch, a working context for message processing, and configurable dispatchers without writing that plumbing by hand. The framework is cross-platform: Windows, Linux, FreeBSD, macOS and Android are listed as supported targets.

Agents, mailboxes and dispatchers: the mechanism behind SObjectizer

The unit of work is an agent, a class derived from so_5::agent_t. Agents are registered in cooperations, which are the grouping and lifecycle unit: the HelloWorld example registers one agent as a cooperation and then calls so_deregister_agent_coop_normally() to finish. Messages are sent to mailboxes. so_5::send<T>(mbox, args...) constructs a message of type T and delivers it asynchronously; the receiving side subscribes in so_define_agent() through so_subscribe_self().event(...) and gets a handler invoked with an mhood_t<T> wrapper. Dispatch is not hard-wired: the documentation describes supplying various ready-to-use dispatchers, which decide where and when handlers run. That is the knob that separates a single-threaded arrangement from a multi-threaded one. Two lifecycle hooks matter in practice: so_evt_start() runs when the agent starts, and so_evt_finish() runs at the end, which the Ping-Pong example uses to print how many pings the ponger received. The same mailbox abstraction also carries the publish-subscribe model and CSP-like channels, so you are not choosing between three libraries.

Installing SObjectizer and running a first agent

SObjectizer-5.8 requires C++17, and the README states that requirement in capitals, so check your compiler before anything else. The two supported dependency-manager routes are vcpkg and Conan, and there is also a direct CMake build. With Conan the README documents adding the package to conanfile.txt and then wiring it into CMakeLists.txt. The exact package name and version string are not reproduced here; take them from the README's Conan section rather than guessing.

#include <so_5/all.hpp>

class hello_actor final : public so_5::agent_t {
public:
   using so_5::agent_t::agent_t;

   void so_evt_start() override {
      std::cout << "Hello, World!" << std::endl;
      so_deregister_agent_coop_normally();
   }
};

That class is the whole agent. It inherits the constructor, prints on start, and deregisters its cooperation so the environment can shut down. The main function launches the framework and registers one instance:

int main() {
   so_5::launch([](so_5::environment_t & env) {
         env.register_agent_as_coop( env.make_agent<hello_actor>() );
      });

   return 0;
}

so_5::launch() starts the environment, runs the lambda, and returns after the cooperation is deregistered. You should see "Hello, World!" on stdout and the process exit cleanly. If the process hangs instead, the usual cause is an agent that never deregisters its cooperation. The Ping-Pong example in the README is the next step: two agents, each holding the other's direct mailbox via so_direct_mbox(), exchanging typed messages until a counter reaches zero.

Where SObjectizer is the wrong choice

The README's own Limitations section is the first place to look, and its headline claim is a limitation in itself: this is not a parallel-computing tool. If your workload is one big computation and you want it faster on more cores, an actor framework adds message-passing overhead and a lifecycle model you do not need. The README says so directly when it dismisses comparisons with TBB, taskflow and HPX. A second constraint is the language level. SObjectizer-5.8 requires C++17, so a codebase pinned to C++14 or older cannot adopt this version without a compiler upgrade. A third is the concurrency model itself: agents communicate only through messages, so any state shared by direct locking sits outside the framework's guarantees and outside its dispatch story. The README does not document rollback for a failed cooperation, and it does not describe what happens to in-flight messages when a cooperation is deregistered. Treat lifecycle design as your responsibility, not the framework's.

SObjectizer versus a task-graph library such as taskflow

The difference is in what the library schedules. A task-graph library models a computation as nodes with dependencies and runs them to completion, which fits a pipeline you can draw in advance. SObjectizer models long-lived agents that react to messages arriving over time, which fits a server or a control loop that never really finishes. In SObjectizer the topology is mailboxes and subscriptions, not an acyclic graph, and agents can subscribe to a shared mailbox to get publish-subscribe semantics without a central broker. The README also notes a companion project, so5extra, for additional facilities, which suggests the core is deliberately kept small. The practical test is whether your program has a natural end state. If it computes an answer and stops, a task graph is a better fit. If it runs indefinitely and reacts, the agent model maps onto the problem more directly.

Maintenance, releases and licence cost

The repository is not archived and the last push was on 2026-09-12, three days before this review, with v5.8.6.1 released on 2026-09-11 and v5.8.6 on 2026-07-28. That is a recent, continuing release cadence, and the README adds context: SObjectizer has been developed since 2002, SObjectizer-5 since 2010, and breaking changes are described as rare and handled carefully. The upgrade cost therefore looks low between minor releases, but the C++17 floor is a one-time, hard migration cost for older codebases. On licensing, the README states that SObjectizer is distributed under BSD-3-Clause and can be used in proprietary commercial software for free. The repository metadata reports the licence as NOASSERTION, so the machine-readable licence field does not match the README's claim; confirm the terms in the LICENSE file at the repository root before you rely on them. This is an observation about the metadata, not legal advice.

Editorial conclusion

Adopt SObjectizer if your problem is many interacting tasks (proxies, brokers, control systems) and you want actors, pub/sub and CSP channels from one C++17 library under BSD-3-Clause. Do not adopt it if your goal is to shorten the runtime of a single compute-heavy job; the README says plainly that it is not like TBB, taskflow or HPX. Before committing, verify three things: that your toolchain supports C++17, that the dispatcher you pick matches your threading model, and that the cooperation shutdown rules fit how your agents are registered. The README documents no rollback procedure for a failed cooperation, so design shutdown paths yourself.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. Stiffstream/sobjectizer on GitHub