惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Jina AI
Jina AI
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
有赞技术团队
有赞技术团队
罗磊的独立博客
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
U
Unit 42
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Recent Announcements
Recent Announcements
Y
Y Combinator Blog
Vercel News
Vercel News
Martin Fowler
Martin Fowler
V
V2EX
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
L
LangChain Blog
云风的 BLOG
云风的 BLOG
H
Hackread – Cybersecurity News, Data Breaches, AI and More
aimingoo的专栏
aimingoo的专栏
G
Google Developers Blog
The GitHub Blog
The GitHub Blog
N
Netflix TechBlog - Medium
Google DeepMind News
Google DeepMind News
雷峰网
雷峰网
阮一峰的网络日志
阮一峰的网络日志
F
Fortinet All Blogs

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
Vix.cpp v2.6.3: Stability, Benchmarks, and a Stronger C++...
Gaspard Kirira · 2026-06-19 · via DEV Community

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.