Component Model for cpp backend · wasmtime

Hi there! First of all, thanks for what you're doing!
I'm a bit new to wasmtime and I have a question about Component Model which I can not resolve because of my lack of knowledge of the platform.

We have a small team and we have a web service created long time ago via cpp with some custom http framework. The service grown to a big monolithic platform designed to be extended by plugins created by our simple plugin mini framework written in cpp as well. The problem we tried to solve is to increase modularity of the service and decrease a chance of failure caused by code in plugins, so a plugin could affect only his internal workspace but not the whole service. But still we have cases where we can not catch exceptions(SIGSEGV) and I decided to take a look to wasm and wasmtime as a possible design solution for a plugin system for our service. And I especially like Component Model proposal.

If it's ok I wanted to ask a few questions to understand how we can adopt this stuff in our team.

Alex Crichton (Sep 08 2026 at 16:01):

Wasm should work well for catching things like segfaults, yeah, so in that sense sounds like a good fit. For WIT vs serialization, that's up to you mostly. You'll in theory take a performance hit doing serialization relative to expressing everything in WIT, but whether or not WIT can express all of what you need depends on your use case. Exceptions can sometimes be represented as the error-part of a result<T, E> in WIT for example, but bindings generators may not take all that into account just yet.

For adoption/extension points, what you'll probably want is to use the C API of Wasmtime (assuming you're a native application). That's probably the easiest way to access Wasmtime from C/C++. There are both *.h headers with a C API and *.hh headers with a C++ API for you to use. I'll note that if you take this route you may want to go with serialization for now as WIT bindings generators for C++ hosts aren't fleshed out yet.

For if you've missed anything, I'd recommend starting things out and seeing how things feel. It'll probably be easier to answer questions grounded in "this thing isn't working" or similar to have something concrete to poke at for example

Christof Petig (Sep 08 2026 at 22:07):

For the C++ bindings we avoided mapping result to exceptions because of tricky memory allocation rules and performance penalties of exceptions (I mostly rely on Herb Sutter's criticism). This might be fixed by some newer compilers. I definitely would like to learn how well it works for you.
When it comes to futures, the code generation is available in my fork of wit-bindgen, but there is no runtime library, yet. Drop me a hint if the code generation alone could help your case, and I will prepare a merge request. The thread primitive needed for future handling recently appeared in wasi-sdk, so it just became feasible.

Victor Adossi (Sep 09 2026 at 11:20):

Also @danie please feel free to take a look at the component model book for more background on components, as well as the design docs available in WebAssembly/component-model when you want to go deeper.

danie (Sep 10 2026 at 09:35):

@Victor Adossi Thanks for the links provided! I have a few things, I'll summarize them and get back to you.

@Alex Crichton @Christof Petig Yes, we use the .hh for Wasmtime and currently pass all of that stuff via serialization. But what I particularly dislike about this approach is that we are creating a bunch of custom proprietary tools which in my view inevitably leads to duct taping. So I'm happy to go with wit even if it's not complete right now if we can adopt our custom types for it. If I understand correctly it will be easier to adopt and move with the stream.
A few more questions.

    auto result = MyFunction_.call(Store_, input);

    if (!result) {
        auto& trap_error = result.err_ref();

        if (auto* trap = std::get_if<wasmtime::Trap>(&trap_error.data)) {
            ....
            trap->code();
            trap->message();
            trap->trace();
        }

        if (auto* error =
            std::get_if<wasmtime::Error>(&trap_error.data)) {
                ...
                error->i32_exit();
                error->message();
                error->trace();
        }
    }

From what I can see I can use result to get trap or error and receive stack trace, message and error code. And it seems like a full exception for me except rtti.

Christof Petig (Sep 10 2026 at 21:42):

Yes, exceptions (throw/catch) are conceptually similar to Result (the way Rust and AUTOSAR adaptive express errors). As I mostly use these environments, I gravitate towards Result instead of throw. Also I experienced a significant slowdown when I used throw&catch for error handling in 2003, so I tend to avoid it ever since.

Christof Petig (Sep 10 2026 at 21:45):

This fork supports async in c++, but it relies on a totally different runtime library.

Stream: wasmtime