Vix.cpp v2.6.3: Stability, Benchmarks, and a Stronger C++ Runtime

Vix.cpp v2.6.3 is now available.

This release is not about adding a huge new feature.

It is about making the foundation stronger.

Vix.cpp is a modern C++ runtime and developer toolkit for building real applications with native C++. It provides a workflow around C++ projects: running files, creating projects, building, testing, packaging, working with modules, and preparing applications for production.

With v2.6.3, the focus is stability.

This release improves the Core runtime, shutdown behavior, HTTP sessions, benchmark infrastructure, CI coverage, sanitizer support, module tests, JSON behavior, and several CLI workflows.

The goal is simple:

stabilize the runtime

measure performance

strengthen CI

make failures easier to trust

Why this release matters

A C++ runtime is not only about API design.

It also has to answer difficult engineering questions:

• Does the server shut down correctly?


• Are async operations cancelled safely?


• Do pending tasks finish or get lost?


• Can test failures be trusted?


• Can benchmarks be repeated?


• Does CI test the right source files?


• Do sanitizer builds link and run correctly?


• Can developers run existing CMake projects without fighting the CLI?

Vix.cpp v2.6.3 focuses on these areas.

It is the kind of release that makes the project less flashy, but more serious.

Better vix run

vix run is one of the most important commands in Vix.cpp.

It can run a project, a single C++ file, a .vix manifest, a binary, and other runtime targets.

In v2.6.3, executable resolution is more reliable for CMake projects.

Before, some projects could fail when the generated binary name did not match the project folder name.

Now vix run can resolve runnable executables more generically.

This also improves project watch mode, because the development workflow no longer assumes that the output binary must have the same name as the directory.

This matters for real CMake projects.

Not every C++ project is generated by Vix. Vix should work with existing C++ projects too.

Better vix tests

Long-running test suites need good progress output.

v2.6.3 improves vix tests so it can show clearer progress during long CTest runs.

The output can now show useful state such as:

completed

total

running

elapsed time

This release also fixes interruption handling.

When the user presses Ctrl+C, Vix now treats it as a user interruption instead of reporting it as a normal test failure.

That distinction matters.

A test failure means the code is wrong.

A user interruption means the user stopped the run.

The CLI should not confuse those two situations.

Core lifecycle fixes

One of the most important parts of this release is Core lifecycle stability.

The Core module is the foundation used by Vix HTTP applications. It connects the public application API with routing, sessions, async I/O, runtime execution, server lifecycle, middleware, requests, responses, and configuration.

v2.6.3 improves shutdown behavior across:

• vix::App


• HTTP server lifecycle


• runtime executor shutdown


• async TCP services


• scheduler shutdown paths


• pending coroutine operations

Some of the important lifecycle fixes include:

• 
  App::close() is now terminal, idempotent, and safe before or after listen().


• 
  App::wait() now closes the running server on signal-stop paths.


• 
  App::listen() prevents closed app instances from being restarted accidentally.


• HTTP server shutdown ordering is safer.


• The accept loop is allowed to drain before stopping the async I/O context.


• TCP listener teardown is safer.


• Server readiness is marked only after the accept loop starts.

These are not cosmetic changes.

They make the runtime more predictable under tests, shutdown races, signal stops, and sanitizer instrumentation.

HTTP session hardening

v2.6.3 also improves HTTP session behavior.

The release fixes parsing and error-response edge cases for:

• malformed requests


• invalid content lengths


• oversized payloads


• unexpected EOF bodies


• case-insensitive Connection: close handling

A framework is easy to test when every request is valid.

Real servers need to behave correctly when clients send bad data, partial data, or edge-case protocol input.

This release makes that layer stronger.

Async shutdown improvements

Async shutdown bugs can be difficult to reproduce.

They often appear only under sanitizers, Valgrind, slow CI machines, or very specific timing conditions.

v2.6.3 improves async TCP shutdown behavior by making close paths safer.

The async TCP stream now cancels pending operations, shuts down the socket, and closes it safely.

The async TCP listener now cancels and closes the acceptor through the Asio executor.

Pending accepts keep the acceptor alive until completion handlers finish.

The scheduler shutdown behavior is also improved so pending coroutine handles are not silently destroyed before completion paths can run.

This helps make the runtime safer when applications stop quickly or when tests force lifecycle edge cases.

Runtime executor fixes

The runtime executor also receives important fixes.

Pending posted tasks are now drained before workers stop.

Idle detection now tracks accepted in-flight tasks before they begin execution.

This avoids a dangerous class of runtime bugs where the executor could appear idle while work had already been accepted but had not started yet.

The runtime worker shutdown path was also improved when yielding tasks are being rescheduled.

This makes task execution and shutdown more deterministic.

Official Core benchmark suite

v2.6.3 adds an official benchmark suite for Vix Core.

This is one of the most important changes in the release.

Performance should not be based on feelings.

It should be measured, stored, compared, and protected.

The Core benchmark suite covers:

runtime.task

runtime.queue

runtime.scheduler

runtime.worker



executor.submit

executor.post

executor.metrics



router.match

router.registration



http.request

http.response



session.fake_transport



app.route_registration

app.group_registration

The release also adds shared benchmark utilities for:

• median time


• mean time


• operations per second


• warmup iterations


• measured samples


• JSON report generation

This gives Vix.cpp a repeatable performance workflow.

Official v2.6.3 benchmark baseline

The official Core v2.6.3 Release benchmark baseline is stored under:

modules/core/benchmarks/baselines/v2.6.3/

The baseline was generated in Release mode on Linux x86_64 with GCC 13.3.0.

Benchmark comparison uses:

median_ops_per_sec

Higher is better.

Default thresholds:

WARN = -5%

FAIL = -10%

The benchmark workflow includes:

scripts/run_core_benchmarks.sh

scripts/compare_core_benchmarks.py

That means future changes can be compared against a known baseline.

If performance improves, it is visible.

If performance regresses, it is visible.

That is the point.

Release builds for real measurements

v2.6.3 also documents an important rule:

dev/debug = compile, test, debug

release   = measure performance

Debug builds are useful for development.

They are not useful for official performance numbers.

Official benchmark baselines should come from Release builds only.

This is the kind of rule that keeps performance discussions honest.

Stricter CI

v2.6.3 strengthens CI in several areas.

Core now has stricter coverage for:

• debug/runtime builds


• sanitizer builds


• Valgrind memory checks


• static analysis


• benchmark builds


• package export validation

The release also improves sanitizer coverage for Core lifecycle, shutdown, executor, session, server, and app behavior.

This matters because lifecycle bugs in C++ are often invisible until sanitizers or memory tools run the code under different timing conditions.

Better static analysis scope

Strict static analysis is useful only when it analyzes the right code.

v2.6.3 improves static analysis scope so third-party files, generated files, examples, benchmarks, and tests are not treated as blocking project source analysis.

This prevents vendored dependencies or disabled optional backends from blocking the release with irrelevant warnings.

The goal is not to make CI weaker.

The goal is to make CI stricter where it matters.

Blocking analysis now focuses on project source files and module implementation sources.

Style-only findings can still be reported separately without blocking the release.

Broader module test coverage

v2.6.3 improves module-level test coverage across the Vix ecosystem.

SECURITY_CI now builds and runs tests inside module directories instead of relying only on root-level test discovery.

This is important because many modules keep their tests close to the module itself.

The release also improves sanitizer-ready test coverage across modules such as:

async

cache

conversion

crypto

env

error

fs

game

io

json

kv

log

middleware

os

path

p2p

process

sync

template

tests

threadpool

time

validation

webrpc

websocket

agent

This makes the whole project more reliable as a modular C++ codebase.

JSON fixes

The JSON module receives an important JPath parsing fix.

Paths after bracket segments now parse correctly.

Examples:

users[0].email

["complex.key"].value

The release also improves JSON module testing, benchmark coverage, examples, and documentation.

This matters because JSON is a core part of many backend and tooling workflows.

Threadpool determinism

The threadpool module receives several deterministic behavior fixes.

v2.6.3 improves future handling for pre-cancelled and queued-cancelled tasks so they resolve deterministically instead of hanging.

Cancellation paths now report cancellation through the associated future.

Tests were also fixed so they do not assume asynchronous work finishes immediately after posting.

That is important.

Threadpool tests should prove behavior, not depend on timing luck.

Highlights

Here are the main highlights of Vix.cpp v2.6.3:

• Improved Core lifecycle and shutdown behavior.


• Fixed HTTP session edge cases.


• Improved async TCP close and shutdown behavior.


• Fixed runtime executor shutdown and idle detection.


• Added the official Core benchmark suite.


• Added the official Core v2.6.3 benchmark baseline.


• Added benchmark run and comparison scripts.


• Improved vix run executable discovery.


• Improved vix tests progress and interruption handling.


• Fixed JSON JPath parsing after bracket segments.


• Strengthened Core test layout.


• Expanded sanitizer coverage across modules.


• Improved static analysis scope.


• Fixed sanitizer linking for module tests.


• Made threadpool cancellation behavior more deterministic.


• Improved CI so it is strict without blocking on irrelevant files.

Why this matters for C++

C++ gives developers performance and control.

But building real applications in C++ often requires a lot of repeated infrastructure:

• build workflows


• test workflows


• runtime diagnostics


• dependency management


• packaging


• production checks


• benchmark tracking


• CI configuration


• module boundaries

Vix.cpp exists to make that application layer more consistent.

v2.6.3 is a step toward that goal.

It makes Vix.cpp less fragile and more measurable.

It also makes the project more honest.

If performance changes, benchmarks should show it.

If shutdown breaks, tests should catch it.

If CI fails, it should fail for the right reason.

Links

GitHub repository:

https://github.com/vixcpp/vix

Release notes:

https://blog.vixcpp.com/posts/changelog/v2.6.3

Core benchmark baseline article:

https://blog.vixcpp.com/posts/vix-core/vix-core-benchmark-baseline-v263

Documentation:

https://docs.vixcpp.com

Final note

Vix.cpp v2.6.3 is not a flashy release.

It is an engineering release.

It improves the parts of a C++ runtime that must be trustworthy:

runtime stability

shutdown behavior

tests

benchmarks

CI

sanitizers

diagnostics

module reliability

That is the long-term direction of Vix.cpp:

native C++

modern workflow

measured performance

strict CI

production-oriented reliability

C++ deserves serious tooling.