Coroutine Machine Process — a C++23 coroutine runtime project.

English · 简体中文 · 繁體中文

mcpp · Architecture · Issues

CMP is being built as a modern coroutine runtime and library on standard stackless C++ coroutines. The intended direction is an explicit co_await model that can grow, in small verified steps, toward scheduling, timers, asynchronous I/O, cancellation, and safe handling of blocking work.

The name stands for Coroutine Machine Process. CMP uses C as the intended name for a lightweight coroutine execution unit. This is analogous to Go runtime's G as a naming and mental-model inspiration only; it is not a claim that a future CMP task is already equivalent to a goroutine.

The project is guided by a few principles:

• use C++23 standard stackless coroutines and C++ Modules;
• keep suspension explicit through co_await and purpose-built awaiters;
• develop runtime pieces incrementally, with tests and small reviewable changes;
• support more than server workloads;
• keep mcpp as the single source of build and package truth.

C++ standard coroutines are a language mechanism, not a complete runtime. CMP therefore does not promise that:

• a task is automatically equivalent to a Go goroutine;
• an arbitrary blocking call becomes non-blocking;
• coroutine switching is safe directly inside a signal handler;
• M:N scheduling, work stealing, timers, cancellation, or async I/O already exist.

Those capabilities must be designed and verified individually. The expected direction is explicit async I/O awaiters, a dedicated blocking pool, and cooperative safe points.

Install xlings, then install the mcpp version pinned by .xlings.json:

xlings install
mcpp --version
mcpp build
mcpp test

Run the standalone consumer:

cd examples/basic
mcpp run

The example exits successfully without output. Its purpose is to prove that an independent mcpp package can resolve the path dependency and import mcpplibs.cmp.

import mcpplibs.cmp;

int main() {
    return 0;
}

The module deliberately has no public declarations during bootstrap. Future public APIs will use the namespace mcpplibs::cmp.

.
├── .xlings.json              # pinned project tool environment
├── mcpp.toml                 # package identity and test dependency
├── src/cmp.cppm              # root module interface
├── tests/cmp_test.cpp        # import smoke test
├── examples/basic/           # standalone path-dependency consumer
├── docs/architecture.md      # current structure, boundaries, and evolution
└── .github/workflows/        # Linux, macOS, and Windows CI

The repository does not ship mcpp new templates yet. Purpose-built templates can be added after CMP has a stable runtime API worth demonstrating.

The local verification path is:

mcpp build --cache=off
mcpp test --cache=off
cd examples/basic && mcpp run

CI runs the equivalent build, test, and standalone example flow on Linux, macOS, and Windows. The mcpp version is pinned by .xlings.json; contributors should not rely on an unrelated global mcpp installation.

CMP does not track mcpp.lock; .gitignore enforces that repository policy. Runtime dependencies belong in [dependencies]; test-only dependencies belong in [dev-dependencies].

Runtime work will be split into independently reviewable phases:

1. package identity and importable-module bootstrap;
2. coroutine task and lifetime semantics;
3. a minimal single-thread scheduler;
4. timers, cancellation, and structured wake-up paths;
5. multi-worker scheduling and work stealing;
6. asynchronous I/O integration and a blocking pool.

The order after the bootstrap is directional, not a promise that any listed feature is already implemented.

Read the architecture notes before changing module boundaries. Keep changes small, use C++23 module conventions, and treat mcpp build, mcpp test, the standalone example, and CI as the implementation facts.

Apache License 2.0