Path: blob/main/crates/c-api/include/wasmtime.h
1692 views
/**1* \mainpage Wasmtime C/C++ API2*3* This documentation is an overview and API reference for the C and C++ API of4* Wasmtime. The C API is spread between three different header files:5*6* * \ref wasmtime.h7* * \ref wasi.h8* * \ref wasm.h9*10* The C++ API builds on the C API and thus is represented in just header files:11*12* * \ref wasmtime.hh13*14* The \ref wasmtime.h header file includes all the other header files and is15* the main header file you'll likely be using. The \ref wasm.h header file16* comes directly from the17* [WebAssembly/wasm-c-api](https://github.com/WebAssembly/wasm-c-api)18* repository, and at this time the upstream header file does not have19* documentation so Wasmtime provides documentation here. It should be noted20* some semantics may be Wasmtime-specific and may not be portable to other21* engines.22*23* ## Installing the C API24*25* To install the C API from precompiled binaries you can download the26* appropriate binary from the [releases page of27* Wasmtime](https://github.com/bytecodealliance/wasmtime/releases). Artifacts28* for the C API all end in "-c-api" for the filename.29*30* Each archive contains an `include` directory with necessary headers, as well31* as a `lib` directory with both a static archive and a dynamic library of32* Wasmtime. You can link to either of them as you see fit.33*34* ## Installing the C API through CMake35*36* CMake can be used to make the process of linking and compiling easier. An37* example of this if you have wasmtime as a git submodule at38* `third_party/wasmtime`:39* ```40* add_subdirectory(${CMAKE_CURRENT_SOURCE_DIR}/third_party/wasmtime/crates/c-api41* ${CMAKE_CURRENT_BINARY_DIR}/wasmtime)42* ...43* target_include_directories(YourProject PUBLIC wasmtime)44* target_link_libraries(YourProject PUBLIC wasmtime)45* ```46* `BUILD_SHARED_LIBS` is provided as a define if you would like to build a47* shared library instead. You must distribute the appropriate shared library48* for your platform if you do this.49*50* ## Linking against the C API51*52* You'll want to arrange the `include` directory of the C API to be in your53* compiler's header path (e.g. the `-I` flag). If you're compiling for Windows54* and you're using the static library then you'll also need to pass55* `-DWASM_API_EXTERN=` and `-DWASI_API_EXTERN=` to disable dllimport.56*57* Your final artifact can then be linked with `-lwasmtime`. If you're linking58* against the static library you may need to pass other system libraries59* depending on your platform:60*61* * Linux - `-lpthread -ldl -lm`62* * macOS - no extra flags needed63* * Windows - `ws2_32.lib advapi32.lib userenv.lib ntdll.lib shell32.lib64* ole32.lib bcrypt.lib`65*66* ## Building from Source67*68* The C API is located in the69* [`crates/c-api`](https://github.com/bytecodealliance/wasmtime/tree/main/crates/c-api)70* directory of the [Wasmtime71* repository](https://github.com/bytecodealliance/wasmtime). To build from72* source you'll need a Rust compiler and a checkout of the `wasmtime` project.73* Afterwards you can execute:74*75* ```76* $ cargo build --release -p wasmtime-c-api77* ```78*79* This will place the final artifacts in `target/release`, with names depending80* on what platform you're compiling for.81*82* ## Other resources83*84* Some other handy resources you might find useful when exploring the C API85* documentation are:86*87* * [Rust `wasmtime` crate88* documentation](https://bytecodealliance.github.io/wasmtime/api/wasmtime/) -89* although this documentation is for Rust and not C, you'll find that many90* functions mirror one another and there may be extra documentation in Rust91* you find helpful. If you find yourself having to frequently do this,92* though, please feel free to [file an93* issue](https://github.com/bytecodealliance/wasmtime/issues/new).94*95* * [C embedding96* examples](https://bytecodealliance.github.io/wasmtime/lang-c.html)97* are available online and are tested from the Wasmtime repository itself.98*99* * [Contribution documentation for100* Wasmtime](https://bytecodealliance.github.io/wasmtime/contributing.html) in101* case you're interested in helping out!102*/103104/**105* \file wasmtime.h106*107* \brief Wasmtime's C API108*109* This file is the central inclusion point for Wasmtime's C API. There are a110* number of sub-header files but this file includes them all. The C API is111* based on \ref wasm.h but there are many Wasmtime-specific APIs which are112* tailored to Wasmtime's implementation.113*114* The #wasm_config_t and #wasm_engine_t types are used from \ref wasm.h.115* Additionally all type-level information (like #wasm_functype_t) is also116* used from \ref wasm.h. Otherwise, though, all wasm objects (like117* #wasmtime_store_t or #wasmtime_func_t) are used from this header file.118*119* ### Thread Safety120*121* The multithreading story of the C API very closely follows the122* multithreading story of the Rust API for Wasmtime. All objects are safe to123* send to other threads so long as user-specific data is also safe to send to124* other threads. Functions are safe to call from any thread but some functions125* cannot be called concurrently. For example, functions which correspond to126* `&T` in Rust can be called concurrently with any other methods that take127* `&T`. Functions that take `&mut T` in Rust, however, cannot be called128* concurrently with any other function (but can still be invoked on any129* thread).130*131* This generally equates to mutation of internal state. Functions which don't132* mutate anything, such as learning type information through133* #wasmtime_func_type, can be called concurrently. Functions which do require134* mutation, for example #wasmtime_func_call, cannot be called concurrently.135* This is conveyed in the C API with either `const wasmtime_context_t*`136* (concurrency is ok as it's read-only) or `wasmtime_context_t*` (concurrency137* is not ok, mutation may happen).138*139* When in doubt assume that functions cannot be called concurrently with140* aliasing objects.141*142* ### Aliasing143*144* The C API for Wasmtime is intended to be a relatively thin layer over the145* Rust API for Wasmtime. Rust has much more strict rules about aliasing than C146* does, and the Rust API for Wasmtime is designed around these rules to be147* used safely. These same rules must be upheld when using the C API of148* Wasmtime.149*150* The main consequence of this is that the #wasmtime_context_t pointer into151* the #wasmtime_store_t must be carefully used. Since the context is an152* internal pointer into the store it must be used carefully to ensure you're153* not doing something that Rust would otherwise forbid at compile time. A154* #wasmtime_context_t can only be used when you would otherwise have been155* provided access to it. For example in a host function created with156* #wasmtime_func_new you can use #wasmtime_context_t in the host function157* callback. This is because an argument, a #wasmtime_caller_t, provides access158* to #wasmtime_context_t.159*160* ### Stores161*162* A foundational construct in this API is the #wasmtime_store_t. A store is a163* collection of host-provided objects and instantiated wasm modules. Stores are164* often treated as a "single unit" and items within a store are all allowed to165* reference one another. References across stores cannot currently be created.166* For example you cannot pass a function from one store into another store.167*168* A store is not intended to be a global long-lived object. Stores provide no169* means of internal garbage collections of wasm objects (such as instances),170* meaning that no memory from a store will be deallocated until you call171* #wasmtime_store_delete. If you're working with a web server, for example,172* then it's recommended to think of a store as a "one per request" sort of173* construct. Globally you'd have one #wasm_engine_t and a cache of174* #wasmtime_module_t instances compiled into that engine. Each request would175* create a new #wasmtime_store_t and then instantiate a #wasmtime_module_t176* into the store. This process of creating a store and instantiating a module177* is expected to be quite fast. When the request is finished you'd delete the178* #wasmtime_store_t keeping memory usage reasonable for the lifetime of the179* server.180*/181182#ifndef WASMTIME_API_H183#define WASMTIME_API_H184185#include <wasi.h>186#include <wasmtime/conf.h>187// clang-format off188// IWYU pragma: begin_exports189#include <wasmtime/config.h>190#include <wasmtime/engine.h>191#include <wasmtime/error.h>192#include <wasmtime/extern.h>193#include <wasmtime/func.h>194#include <wasmtime/global.h>195#include <wasmtime/instance.h>196#include <wasmtime/linker.h>197#include <wasmtime/memory.h>198#include <wasmtime/module.h>199#include <wasmtime/profiling.h>200#include <wasmtime/sharedmemory.h>201#include <wasmtime/store.h>202#include <wasmtime/table.h>203#include <wasmtime/trap.h>204#include <wasmtime/val.h>205#include <wasmtime/async.h>206#include <wasmtime/component.h>207#include <wasmtime/wasip2.h>208#include <wasmtime/wat.h>209// IWYU pragma: end_exports210// clang-format on211212/**213* \brief Wasmtime version string.214*/215#define WASMTIME_VERSION "38.0.0"216/**217* \brief Wasmtime major version number.218*/219#define WASMTIME_VERSION_MAJOR 38220/**221* \brief Wasmtime minor version number.222*/223#define WASMTIME_VERSION_MINOR 0224/**225* \brief Wasmtime patch version number.226*/227#define WASMTIME_VERSION_PATCH 0228229#endif // WASMTIME_API_H230231232