| feature | description |
|---|---|
| link-time replaceable |
Allows the std library to know at link-time which services to construct. Allows specified construction order of services by the std library. When the order is specified, this enables deterministic reasoning about dependencies for users and replacement implementations. Prevents any need to address the complexities of runtime replacement in the specification or in the implementation (eg. when to construct, when to destruct, how many replacements allowed, when are replacements allowed, what happens when an invalid replacement is attempted, etc..). |
| cannonical across all stdlib implementations |
libraries like TBB and Qt implement a replacement once and that works with all std libraries. |
| user provided storage |
minimize allocations by allowing a user to supply storage for an operation |
| user provided allocator | Allows the user to determine how operations allocate additional storage |
| asynchronous construction and asynchronous destruction |
This allows the system_context to use non-blocking asynchronous operations during construction and destruction. This allows construction and destruction of future contexts, such as an IO context, to be interleaved/concurrent with the system_context. |
| specified construction order |
The order of the construction of services provided by the std lib is specified in start and term sections of the std. This allows the std to specify allowed dependencies between other activities during start and term. This allows the std to specify allowed dependencies between existing and future services. Are static global objects allowed to use the system_context in the constructor or destructor? Is a future IO context allowed to use the system_context? The specification of a deterministic order is not for std library implementors. The specification of a deterministic order enables reasoning about lifetimes and dependencies for users of the system_context and for system_context replacement implementations and for future contexts like an IO context. |
| compile-time versioned |
Specify how to version types that change or extend the ABI. When additional features are added to the system context how does that look in the type-system? std::execution::system_context -> std::execution::system_context2?or std::execution::v1::system_context -> std::execution::v2::system_context? |
| run-time versioned |
The user can inspect the run-time version of the implementation and use that to select a different code-path. This allows an implementation of v2 system_context to be used as the implementation of the v1 system_context and then when the v1 system_context is passed by an app or a library to a library that is aware of v2, the library will be able to recognize at runtime that the provided v1 system_context has a v2 implementation and use the v1 system_context as a v2 system_context |
| run-time extensible |
A replacement can expose additional functionality and code has a mechanism to query for that functionality at runtime An example might be that the replacements provided by hpux, TBB, Qt, and ASIO might expose tuning options and additional features (eg. IO) |
| backward- compatible |
This means that it is specified how existing code using the system_context and existing replacements of the system_context are not affected by changes to the ABI over time. The ABI explicitly specifies how to: - add features - remove features - change features without breaking any existing users or libraries or std libraries or compiled binaries. |
| feature | Paper | POC godbolt |
|---|---|---|
| link-time replaceable | ✅ | ✅ |
| cannonical across all stdlib implementations |
✅ | ✅ |
| user provided storage | ✅ | ✅ |
| user provided allocator | ❌ | ❌ |
| asynchronous construction and asynchronous destruction |
❌ | ✅ |
| specified construction order | ❌ | ✅ |
| compile-time versioned | ❌ | ✅ |
| run-time versioned | ❌ | ✅ |
| run-time extensible | ❌ | ✅ |
| backward-compatible | ❌ | ✅ |