Struct wasmtime::Config

pub struct Config { /* fields omitted */ }

Global configuration options used to create an Engine and customize its behavior.

This structure exposed a builder-like interface and is primarily consumed by Engine::new()

Implementations

impl Config

pub fn new() -> Self

Creates a new configuration object with the default configuration specified.

pub fn target(&mut self, target: &str) -> Result<&mut Self>

Sets the target triple for the Config.

By default, the host target triple is used for the Config.

This method can be used to change the target triple.

Cranelift flags will not be inferred for the given target and any existing target-specific Cranelift flags will be cleared.

Errors

This method will error if the given target triple is not supported.

pub fn async_support(&mut self, enable: bool) -> &mut Self

Whether or not to enable support for asynchronous functions in Wasmtime.

When enabled, the config can optionally define host functions with async. Instances created and functions called with this Config must be called through their asynchronous APIs, however. For example using Func::call will panic when used with this config.

Asynchronous Wasm

WebAssembly does not currently have a way to specify at the bytecode level what is and isn’t async. Host-defined functions, however, may be defined as async. WebAssembly imports always appear synchronous, which gives rise to a bit of an impedance mismatch here. To solve this Wasmtime supports “asynchronous configs” which enables calling these asynchronous functions in a way that looks synchronous to the executing WebAssembly code.

An asynchronous config must always invoke wasm code asynchronously, meaning we’ll always represent its computation as a Future. The poll method of the futures returned by Wasmtime will perform the actual work of calling the WebAssembly. Wasmtime won’t manage its own thread pools or similar, that’s left up to the embedder.

To implement futures in a way that WebAssembly sees asynchronous host functions as synchronous, all async Wasmtime futures will execute on a separately allocated native stack from the thread otherwise executing Wasmtime. This separate native stack can then be switched to and from. Using this whenever an async host function returns a future that resolves to Pending we switch away from the temporary stack back to the main stack and propagate the Pending status.

In general it’s encouraged that the integration with async and wasmtime is designed early on in your embedding of Wasmtime to ensure that it’s planned that WebAssembly executes in the right context of your application.

Execution in poll

The Future::poll method is the main driving force behind Rust’s futures. That method’s own documentation states “an implementation of poll should strive to return quickly, and should not block”. This, however, can be at odds with executing WebAssembly code as part of the poll method itself. If your WebAssembly is untrusted then this could allow the poll method to take arbitrarily long in the worst case, likely blocking all other asynchronous tasks.

To remedy this situation you have a two possible ways to solve this:

• First you can spawn futures into a thread pool. Care must be taken for this because Wasmtime futures are not Send or Sync. If you ensure that the entire state of a Store is wrapped up in a single future, though, you can send the whole future at once to a separate thread. By doing this in a thread pool you are relaxing the requirement that Future::poll must be fast because your future is executing on a separate thread. This strategy, however, would likely still require some form of cancellation via crate::Store::interrupt_handle to ensure wasm doesn’t take too long to execute.

• Alternatively you can enable the Config::consume_fuel method as well as crate::Store::out_of_fuel_async_yield When doing so this will configure Wasmtime futures to yield periodically while they’re executing WebAssembly code. After consuming the specified amount of fuel wasm futures will return Poll::Pending from their poll method, and will get automatically re-polled later. This enables the Future::poll method to take roughly a fixed amount of time since fuel is guaranteed to get consumed while wasm is executing. Note that to prevent infinite execution of wasm you’ll still need to use crate::Store::interrupt_handle.

In either case special care needs to be taken when integrating asynchronous wasm into your application. You should carefully plan where WebAssembly will execute and what compute resources will be allotted to it. If Wasmtime doesn’t support exactly what you’d like just yet, please feel free to open an issue!

pub fn debug_info(&mut self, enable: bool) -> &mut Self

Configures whether DWARF debug information will be emitted during compilation.

By default this option is false.

pub fn wasm_backtrace_details(
    &mut self,
    enable: WasmBacktraceDetails
) -> &mut Self

Configures whether backtraces in Trap will parse debug info in the wasm file to have filename/line number information.

When enabled this will causes modules to retain debugging information found in wasm binaries. This debug information will be used when a trap happens to symbolicate each stack frame and attempt to print a filename/line number for each wasm frame in the stack trace.

By default this option is WasmBacktraceDetails::Environment, meaning that wasm will read WASMTIME_BACKTRACE_DETAILS to indicate whether details should be parsed.

pub fn interruptable(&mut self, enable: bool) -> &mut Self

Configures whether functions and loops will be interruptable via the Store::interrupt_handle method.

For more information see the documentation on Store::interrupt_handle.

By default this option is false.

pub fn consume_fuel(&mut self, enable: bool) -> &mut Self

Configures whether execution of WebAssembly will “consume fuel” to either halt or yield execution as desired.

This option is similar in purpose to Config::interruptable where you can prevent infinitely-executing WebAssembly code. The difference is that this option allows deterministic execution of WebAssembly code by instrumenting generated code consume fuel as it executes. When fuel runs out the behavior is defined by configuration within a Store, and by default a trap is raised.

Note that a Store starts with no fuel, so if you enable this option you’ll have to be sure to pour some fuel into Store before executing some code.

By default this option is false.

pub fn max_wasm_stack(&mut self, size: usize) -> Result<&mut Self>

Configures the maximum amount of stack space available for executing WebAssembly code.

WebAssembly has well-defined semantics on stack overflow. This is intended to be a knob which can help configure how much stack space wasm execution is allowed to consume. Note that the number here is not super-precise, but rather wasm will take at most “pretty close to this much” stack space.

If a wasm call (or series of nested wasm calls) take more stack space than the size specified then a stack overflow trap will be raised.

When the async feature is enabled, this value cannot exceed the async_stack_size option. Be careful not to set this value too close to async_stack_size as doing so may limit how much stack space is available for host functions. Unlike wasm functions that trap on stack overflow, a host function that overflows the stack will abort the process.

By default this option is 1 MiB.

pub fn async_stack_size(&mut self, size: usize) -> Result<&mut Self>

Configures the size of the stacks used for asynchronous execution.

This setting configures the size of the stacks that are allocated for asynchronous execution. The value cannot be less than max_wasm_stack.

The amount of stack space guaranteed for host functions is async_stack_size - max_wasm_stack, so take care not to set these two values close to one another; doing so may cause host functions to overflow the stack and abort the process.

By default this option is 2 MiB.

pub fn wasm_threads(&mut self, enable: bool) -> &mut Self

Configures whether the WebAssembly threads proposal will be enabled for compilation.

The WebAssembly threads proposal is not currently fully standardized and is undergoing development. Additionally the support in wasmtime itself is still being worked on. Support for this feature can be enabled through this method for appropriate wasm modules.

This feature gates items such as shared memories and atomic instructions. Note that enabling the threads feature will also enable the bulk memory feature.

This is false by default.

Note: Wasmtime does not implement everything for the wasm threads spec at this time, so bugs, panics, and possibly segfaults should be expected. This should not be enabled in a production setting right now.

pub fn wasm_reference_types(&mut self, enable: bool) -> &mut Self

Configures whether the WebAssembly reference types proposal will be enabled for compilation.

This feature gates items such as the externref and funcref types as well as allowing a module to define multiple tables.

Note that enabling the reference types feature will also enable the bulk memory feature.

This is true by default on x86-64, and false by default on other architectures.

pub fn wasm_simd(&mut self, enable: bool) -> &mut Self

Configures whether the WebAssembly SIMD proposal will be enabled for compilation.

The WebAssembly SIMD proposal is not currently fully standardized and is undergoing development. Additionally the support in wasmtime itself is still being worked on. Support for this feature can be enabled through this method for appropriate wasm modules.

This feature gates items such as the v128 type and all of its operators being in a module.

This is false by default.

Note: Wasmtime does not implement everything for the wasm simd spec at this time, so bugs, panics, and possibly segfaults should be expected. This should not be enabled in a production setting right now.

pub fn wasm_bulk_memory(&mut self, enable: bool) -> &mut Self

Configures whether the WebAssembly bulk memory operations proposal will be enabled for compilation.

This feature gates items such as the memory.copy instruction, passive data/table segments, etc, being in a module.

This is true by default.

pub fn wasm_multi_value(&mut self, enable: bool) -> &mut Self

Configures whether the WebAssembly multi-value proposal will be enabled for compilation.

This feature gates functions and blocks returning multiple values in a module, for example.

This is true by default.

pub fn wasm_multi_memory(&mut self, enable: bool) -> &mut Self

Configures whether the WebAssembly multi-memory proposal will be enabled for compilation.

This feature gates modules having more than one linear memory declaration or import.

This is false by default.

pub fn wasm_module_linking(&mut self, enable: bool) -> &mut Self

Configures whether the WebAssembly module linking proposal will be enabled for compilation.

Note that development of this feature is still underway, so enabling this is likely to be full of bugs.

This is false by default.

pub fn strategy(&mut self, strategy: Strategy) -> Result<&mut Self>

Configures which compilation strategy will be used for wasm modules.

This method can be used to configure which compiler is used for wasm modules, and for more documentation consult the Strategy enumeration and its documentation.

The default value for this is Strategy::Auto.

Errors

Some compilation strategies require compile-time options of wasmtime itself to be set, but if they’re not set and the strategy is specified here then an error will be returned.

pub fn profiler(&mut self, profile: ProfilingStrategy) -> Result<&mut Self>

Creates a default profiler based on the profiling strategy chosen.

Profiler creation calls the type’s default initializer where the purpose is really just to put in place the type used for profiling.

pub fn cranelift_debug_verifier(&mut self, enable: bool) -> &mut Self

Configures whether the debug verifier of Cranelift is enabled or not.

When Cranelift is used as a code generation backend this will configure it to have the enable_verifier flag which will enable a number of debug checks inside of Cranelift. This is largely only useful for the developers of wasmtime itself.

The default value for this is false

pub fn cranelift_opt_level(&mut self, level: OptLevel) -> &mut Self

Configures the Cranelift code generator optimization level.

When the Cranelift code generator is used you can configure the optimization level used for generated code in a few various ways. For more information see the documentation of OptLevel.

The default value for this is OptLevel::None.

pub fn cranelift_nan_canonicalization(&mut self, enable: bool) -> &mut Self

Configures whether Cranelift should perform a NaN-canonicalization pass.

When Cranelift is used as a code generation backend this will configure it to replace NaNs with a single canonical value. This is useful for users requiring entirely deterministic WebAssembly computation. This is not required by the WebAssembly spec, so it is not enabled by default.

The default value for this is false

pub unsafe fn cranelift_flag_enable(&mut self, flag: &str) -> Result<&mut Self>

Allows setting a Cranelift boolean flag or preset. This allows fine-tuning of Cranelift settings.

Since Cranelift flags may be unstable, this method should not be considered to be stable either; other Config functions should be preferred for stability.

Safety

This is marked as unsafe, because setting the wrong flag might break invariants, resulting in execution hazards.

Errors

This method can fail if the flag’s name does not exist.

pub unsafe fn cranelift_flag_set(
    &mut self,
    name: &str,
    value: &str
) -> Result<&mut Self>

Allows settings another Cranelift flag defined by a flag name and value. This allows fine-tuning of Cranelift settings.

Since Cranelift flags may be unstable, this method should not be considered to be stable either; other Config functions should be preferred for stability.

Note that this is marked as unsafe, because setting the wrong flag might break invariants, resulting in execution hazards.

Errors

This method can fail if the flag’s name does not exist, or the value is not appropriate for the flag type.

pub fn cache_config_load(&mut self, path: impl AsRef<Path>) -> Result<&mut Self>

Loads cache configuration specified at path.

This method will read the file specified by path on the filesystem and attempt to load cache configuration from it. This method can also fail due to I/O errors, misconfiguration, syntax errors, etc. For expected syntax in the configuration file see the documentation online.

By default cache configuration is not enabled or loaded.

This method is only available when the cache feature of this crate is enabled.

Errors

This method can fail due to any error that happens when loading the file pointed to by path and attempting to load the cache configuration.

pub fn cache_config_load_default(&mut self) -> Result<&mut Self>

Loads cache configuration from the system default path.

This commit is the same as Config::cache_config_load except that it does not take a path argument and instead loads the default configuration present on the system. This is located, for example, on Unix at $HOME/.config/wasmtime/config.toml and is typically created with the wasmtime config new command.

By default cache configuration is not enabled or loaded.

This method is only available when the cache feature of this crate is enabled.

Errors

This method can fail due to any error that happens when loading the default system configuration. Note that it is not an error if the default config file does not exist, in which case the default settings for an enabled cache are applied.

pub fn with_host_memory(
    &mut self,
    mem_creator: Arc<dyn MemoryCreator>
) -> &mut Self

Sets a custom memory creator.

Custom memory creators are used when creating host Memory objects or when creating instance linear memories for the on-demand instance allocation strategy.

pub fn allocation_strategy(
    &mut self,
    strategy: InstanceAllocationStrategy
) -> &mut Self

Sets the instance allocation strategy to use.

When using the pooling instance allocation strategy, all linear memories will be created as “static”.

This means the Config::static_memory_maximum_size and Config::static_memory_guard_size options will be ignored in favor of InstanceLimits::memory_reservation_size when the pooling instance allocation strategy is used.

pub fn static_memory_maximum_size(&mut self, max_size: u64) -> &mut Self

Configures the maximum size, in bytes, where a linear memory is considered static, above which it’ll be considered dynamic.

This function configures the threshold for wasm memories whether they’re implemented as a dynamically relocatable chunk of memory or a statically located chunk of memory. The max_size parameter here is the size, in bytes, where if the maximum size of a linear memory is below max_size then it will be statically allocated with enough space to never have to move. If the maximum size of a linear memory is larger than max_size then wasm memory will be dynamically located and may move in memory through growth operations.

Specifying a max_size of 0 means that all memories will be dynamic and may be relocated through memory.grow. Also note that if any wasm memory’s maximum size is below max_size then it will still reserve max_size bytes in the virtual memory space.

Static vs Dynamic Memory

Linear memories represent contiguous arrays of bytes, but they can also be grown through the API and wasm instructions. When memory is grown if space hasn’t been preallocated then growth may involve relocating the base pointer in memory. Memories in Wasmtime are classified in two different ways:

• static - these memories preallocate all space necessary they’ll ever need, meaning that the base pointer of these memories is never moved. Static memories may take more virtual memory space because of pre-reserving space for memories.

• dynamic - these memories are not preallocated and may move during growth operations. Dynamic memories consume less virtual memory space because they don’t need to preallocate space for future growth.

Static memories can be optimized better in JIT code because once the base address is loaded in a function it’s known that we never need to reload it because it never changes, memory.grow is generally a pretty fast operation because the wasm memory is never relocated, and under some conditions bounds checks can be elided on memory accesses.

Dynamic memories can’t be quite as heavily optimized because the base address may need to be reloaded more often, they may require relocating lots of data on memory.grow, and dynamic memories require unconditional bounds checks on all memory accesses.

Should you use static or dynamic memory?

In general you probably don’t need to change the value of this property. The defaults here are optimized for each target platform to consume a reasonable amount of physical memory while also generating speedy machine code.

One of the main reasons you may want to configure this today is if your environment can’t reserve virtual memory space for each wasm linear memory. On 64-bit platforms wasm memories require a 6GB reservation by default, and system limits may prevent this in some scenarios. In this case you may wish to force memories to be allocated dynamically meaning that the virtual memory footprint of creating a wasm memory should be exactly what’s used by the wasm itself.

For 32-bit memories a static memory must contain at least 4GB of reserved address space plus a guard page to elide any bounds checks at all. Smaller static memories will use similar bounds checks as dynamic memories.

Default

The default value for this property depends on the host platform. For 64-bit platforms there’s lots of address space available, so the default configured here is 4GB. WebAssembly linear memories currently max out at 4GB which means that on 64-bit platforms Wasmtime by default always uses a static memory. This, coupled with a sufficiently sized guard region, should produce the fastest JIT code on 64-bit platforms, but does require a large address space reservation for each wasm memory.

For 32-bit platforms this value defaults to 1GB. This means that wasm memories whose maximum size is less than 1GB will be allocated statically, otherwise they’ll be considered dynamic.

pub fn static_memory_guard_size(&mut self, guard_size: u64) -> &mut Self

Configures the size, in bytes, of the guard region used at the end of a static memory’s address space reservation.

All WebAssembly loads/stores are bounds-checked and generate a trap if they’re out-of-bounds. Loads and stores are often very performance critical, so we want the bounds check to be as fast as possible! Accelerating these memory accesses is the motivation for a guard after a memory allocation.

Memories (both static and dynamic) can be configured with a guard at the end of them which consists of unmapped virtual memory. This unmapped memory will trigger a memory access violation (e.g. segfault) if accessed. This allows JIT code to elide bounds checks if it can prove that an access, if out of bounds, would hit the guard region. This means that having such a guard of unmapped memory can remove the need for bounds checks in JIT code.

For the difference between static and dynamic memories, see the Config::static_memory_maximum_size.

How big should the guard be?

In general, like with configuring static_memory_maximum_size, you probably don’t want to change this value from the defaults. Otherwise, though, the size of the guard region affects the number of bounds checks needed for generated wasm code. More specifically, loads/stores with immediate offsets will generate bounds checks based on how big the guard page is.

For 32-bit memories a 4GB static memory is required to even start removing bounds checks. A 4GB guard size will guarantee that the module has zero bounds checks for memory accesses. A 2GB guard size will eliminate all bounds checks with an immediate offset less than 2GB. A guard size of zero means that all memory accesses will still have bounds checks.

Default

The default value for this property is 2GB on 64-bit platforms. This allows eliminating almost all bounds checks on loads/stores with an immediate offset of less than 2GB. On 32-bit platforms this defaults to 64KB.

Static vs Dynamic Guard Size

Note that for now the static memory guard size must be at least as large as the dynamic memory guard size, so configuring this property to be smaller than the dynamic memory guard size will have no effect.

pub fn dynamic_memory_guard_size(&mut self, guard_size: u64) -> &mut Self

Configures the size, in bytes, of the guard region used at the end of a dynamic memory’s address space reservation.

For the difference between static and dynamic memories, see the Config::static_memory_maximum_size

For more information about what a guard is, see the documentation on Config::static_memory_guard_size.

Note that the size of the guard region for dynamic memories is not super critical for performance. Making it reasonably-sized can improve generated code slightly, but for maximum performance you’ll want to lean towards static memories rather than dynamic anyway.

Also note that the dynamic memory guard size must be smaller than the static memory guard size, so if a large dynamic memory guard is specified then the static memory guard size will also be automatically increased.

Default

This value defaults to 64KB.

pub fn max_instances(&mut self, instances: usize) -> &mut Self

Configures the maximum number of instances which can be created within this Store.

Instantiation will fail with an error if this limit is exceeded.

This value defaults to 10,000.

pub fn max_tables(&mut self, tables: usize) -> &mut Self

Configures the maximum number of tables which can be created within this Store.

Instantiation will fail with an error if this limit is exceeded.

This value defaults to 10,000.

pub fn max_memories(&mut self, memories: usize) -> &mut Self

Configures the maximum number of memories which can be created within this Store.

Instantiation will fail with an error if this limit is exceeded.

This value defaults to 10,000.

pub fn define_host_func(
    &mut self,
    module: &str,
    name: &str,
    ty: FuncType,
    func: impl Fn(Caller<'_>, &[Val], &mut [Val]) -> Result<(), Trap> + Send + Sync + 'static
)

Defines a host function for the Config for the given callback.

Use Store::get_host_func to get a Func representing the function.

Note that the implementation of func must adhere to the ty signature given, error or traps may occur if it does not respect the ty signature.

Additionally note that this is quite a dynamic function since signatures are not statically known. For performance reasons, it’s recommended to use Config::wrap_host_func if you can because with statically known signatures the engine can optimize the implementation much more.

The callback must be Send and Sync as it is shared between all engines created from the Config. For more relaxed bounds, use Func::new to define the function.

pub fn define_host_func_async<F>(
    &mut self,
    module: &str,
    name: &str,
    ty: FuncType,
    func: F
) where
    F: for<'a> Fn(Caller<'a>, &'a [Val], &'a mut [Val]) -> Box<dyn Future<Output = Result<(), Trap>> + 'a> + Send + Sync + 'static, 

Defines an async host function for the Config for the given callback.

Use Store::get_host_func to get a Func representing the function.

This function is the asynchronous analogue of Config::define_host_func and much of that documentation applies to this as well.

Additionally note that this is quite a dynamic function since signatures are not statically known. For performance reasons, it’s recommended to use Config::wrap$N_host_func_async if you can because with statically known signatures the engine can optimize the implementation much more.

The callback must be Send and Sync as it is shared between all engines created from the Config. For more relaxed bounds, use Func::new_async to define the function.

Note: creating an engine will fail if an async host function is defined and async support is not enabled.

pub fn wrap_host_func<Params, Results>(
    &mut self,
    module: &str,
    name: &str,
    func: impl IntoFunc<Params, Results> + Send + Sync
)

Defines a host function for the Config from the given Rust closure.

Use Store::get_host_func to get a Func representing the function.

See Func::wrap for information about accepted parameter and result types for the closure.

The closure must be Send and Sync as it is shared between all engines created from the Config. For more relaxed bounds, use Func::wrap to wrap the closure.

pub fn wrap0_host_func_async<R>(
    &mut self,
    module: &str,
    name: &str,
    func: impl for<'a> Fn(Caller<'a>) -> Box<dyn Future<Output = R> + 'a> + Send + Sync + 'static
) where
    R: WasmRet, 

Same as Config::wrap_host_func, except the closure asynchronously produces its result. For more information see the Func documentation.

Note: creating an engine will fail if an async host function is defined and async support is not enabled.

pub fn wrap1_host_func_async<A1, R>(
    &mut self,
    module: &str,
    name: &str,
    func: impl for<'a> Fn(Caller<'a>, A1) -> Box<dyn Future<Output = R> + 'a> + Send + Sync + 'static
) where
    A1: WasmTy,
    R: WasmRet, 

Same as Config::wrap_host_func, except the closure asynchronously produces its result. For more information see the Func documentation.

Note: creating an engine will fail if an async host function is defined and async support is not enabled.

pub fn wrap2_host_func_async<A1, A2, R>(
    &mut self,
    module: &str,
    name: &str,
    func: impl for<'a> Fn(Caller<'a>, A1, A2) -> Box<dyn Future<Output = R> + 'a> + Send + Sync + 'static
) where
    A1: WasmTy,
    A2: WasmTy,
    R: WasmRet, 

Same as Config::wrap_host_func, except the closure asynchronously produces its result. For more information see the Func documentation.

Note: creating an engine will fail if an async host function is defined and async support is not enabled.

pub fn wrap3_host_func_async<A1, A2, A3, R>(
    &mut self,
    module: &str,
    name: &str,
    func: impl for<'a> Fn(Caller<'a>, A1, A2, A3) -> Box<dyn Future<Output = R> + 'a> + Send + Sync + 'static
) where
    A1: WasmTy,
    A2: WasmTy,
    A3: WasmTy,
    R: WasmRet, 

Same as Config::wrap_host_func, except the closure asynchronously produces its result. For more information see the Func documentation.

Note: creating an engine will fail if an async host function is defined and async support is not enabled.

pub fn wrap4_host_func_async<A1, A2, A3, A4, R>(
    &mut self,
    module: &str,
    name: &str,
    func: impl for<'a> Fn(Caller<'a>, A1, A2, A3, A4) -> Box<dyn Future<Output = R> + 'a> + Send + Sync + 'static
) where
    A1: WasmTy,
    A2: WasmTy,
    A3: WasmTy,
    A4: WasmTy,
    R: WasmRet, 

Same as Config::wrap_host_func, except the closure asynchronously produces its result. For more information see the Func documentation.

Note: creating an engine will fail if an async host function is defined and async support is not enabled.

pub fn wrap5_host_func_async<A1, A2, A3, A4, A5, R>(
    &mut self,
    module: &str,
    name: &str,
    func: impl for<'a> Fn(Caller<'a>, A1, A2, A3, A4, A5) -> Box<dyn Future<Output = R> + 'a> + Send + Sync + 'static
) where
    A1: WasmTy,
    A2: WasmTy,
    A3: WasmTy,
    A4: WasmTy,
    A5: WasmTy,
    R: WasmRet, 

Same as Config::wrap_host_func, except the closure asynchronously produces its result. For more information see the Func documentation.

Note: creating an engine will fail if an async host function is defined and async support is not enabled.

pub fn wrap6_host_func_async<A1, A2, A3, A4, A5, A6, R>(
    &mut self,
    module: &str,
    name: &str,
    func: impl for<'a> Fn(Caller<'a>, A1, A2, A3, A4, A5, A6) -> Box<dyn Future<Output = R> + 'a> + Send + Sync + 'static
) where
    A1: WasmTy,
    A2: WasmTy,
    A3: WasmTy,
    A4: WasmTy,
    A5: WasmTy,
    A6: WasmTy,
    R: WasmRet, 

Same as Config::wrap_host_func, except the closure asynchronously produces its result. For more information see the Func documentation.

Note: creating an engine will fail if an async host function is defined and async support is not enabled.

pub fn wrap7_host_func_async<A1, A2, A3, A4, A5, A6, A7, R>(
    &mut self,
    module: &str,
    name: &str,
    func: impl for<'a> Fn(Caller<'a>, A1, A2, A3, A4, A5, A6, A7) -> Box<dyn Future<Output = R> + 'a> + Send + Sync + 'static
) where
    A1: WasmTy,
    A2: WasmTy,
    A3: WasmTy,
    A4: WasmTy,
    A5: WasmTy,
    A6: WasmTy,
    A7: WasmTy,
    R: WasmRet, 

Same as Config::wrap_host_func, except the closure asynchronously produces its result. For more information see the Func documentation.

Note: creating an engine will fail if an async host function is defined and async support is not enabled.

pub fn wrap8_host_func_async<A1, A2, A3, A4, A5, A6, A7, A8, R>(
    &mut self,
    module: &str,
    name: &str,
    func: impl for<'a> Fn(Caller<'a>, A1, A2, A3, A4, A5, A6, A7, A8) -> Box<dyn Future<Output = R> + 'a> + Send + Sync + 'static
) where
    A1: WasmTy,
    A2: WasmTy,
    A3: WasmTy,
    A4: WasmTy,
    A5: WasmTy,
    A6: WasmTy,
    A7: WasmTy,
    A8: WasmTy,
    R: WasmRet, 

Same as Config::wrap_host_func, except the closure asynchronously produces its result. For more information see the Func documentation.

Note: creating an engine will fail if an async host function is defined and async support is not enabled.

pub fn wrap9_host_func_async<A1, A2, A3, A4, A5, A6, A7, A8, A9, R>(
    &mut self,
    module: &str,
    name: &str,
    func: impl for<'a> Fn(Caller<'a>, A1, A2, A3, A4, A5, A6, A7, A8, A9) -> Box<dyn Future<Output = R> + 'a> + Send + Sync + 'static
) where
    A1: WasmTy,
    A2: WasmTy,
    A3: WasmTy,
    A4: WasmTy,
    A5: WasmTy,
    A6: WasmTy,
    A7: WasmTy,
    A8: WasmTy,
    A9: WasmTy,
    R: WasmRet, 

Same as Config::wrap_host_func, except the closure asynchronously produces its result. For more information see the Func documentation.

Note: creating an engine will fail if an async host function is defined and async support is not enabled.

pub fn wrap10_host_func_async<A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, R>(
    &mut self,
    module: &str,
    name: &str,
    func: impl for<'a> Fn(Caller<'a>, A1, A2, A3, A4, A5, A6, A7, A8, A9, A10) -> Box<dyn Future<Output = R> + 'a> + Send + Sync + 'static
) where
    A1: WasmTy,
    A2: WasmTy,
    A3: WasmTy,
    A4: WasmTy,
    A5: WasmTy,
    A6: WasmTy,
    A7: WasmTy,
    A8: WasmTy,
    A9: WasmTy,
    A10: WasmTy,
    R: WasmRet, 

Same as Config::wrap_host_func, except the closure asynchronously produces its result. For more information see the Func documentation.

Note: creating an engine will fail if an async host function is defined and async support is not enabled.

pub fn wrap11_host_func_async<A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, R>(
    &mut self,
    module: &str,
    name: &str,
    func: impl for<'a> Fn(Caller<'a>, A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11) -> Box<dyn Future<Output = R> + 'a> + Send + Sync + 'static
) where
    A1: WasmTy,
    A2: WasmTy,
    A3: WasmTy,
    A4: WasmTy,
    A5: WasmTy,
    A6: WasmTy,
    A7: WasmTy,
    A8: WasmTy,
    A9: WasmTy,
    A10: WasmTy,
    A11: WasmTy,
    R: WasmRet, 

Same as Config::wrap_host_func, except the closure asynchronously produces its result. For more information see the Func documentation.

Note: creating an engine will fail if an async host function is defined and async support is not enabled.

pub fn wrap12_host_func_async<A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, R>(
    &mut self,
    module: &str,
    name: &str,
    func: impl for<'a> Fn(Caller<'a>, A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12) -> Box<dyn Future<Output = R> + 'a> + Send + Sync + 'static
) where
    A1: WasmTy,
    A2: WasmTy,
    A3: WasmTy,
    A4: WasmTy,
    A5: WasmTy,
    A6: WasmTy,
    A7: WasmTy,
    A8: WasmTy,
    A9: WasmTy,
    A10: WasmTy,
    A11: WasmTy,
    A12: WasmTy,
    R: WasmRet, 

Same as Config::wrap_host_func, except the closure asynchronously produces its result. For more information see the Func documentation.

Note: creating an engine will fail if an async host function is defined and async support is not enabled.

pub fn wrap13_host_func_async<A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13, R>(
    &mut self,
    module: &str,
    name: &str,
    func: impl for<'a> Fn(Caller<'a>, A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13) -> Box<dyn Future<Output = R> + 'a> + Send + Sync + 'static
) where
    A1: WasmTy,
    A2: WasmTy,
    A3: WasmTy,
    A4: WasmTy,
    A5: WasmTy,
    A6: WasmTy,
    A7: WasmTy,
    A8: WasmTy,
    A9: WasmTy,
    A10: WasmTy,
    A11: WasmTy,
    A12: WasmTy,
    A13: WasmTy,
    R: WasmRet, 

Same as Config::wrap_host_func, except the closure asynchronously produces its result. For more information see the Func documentation.

Note: creating an engine will fail if an async host function is defined and async support is not enabled.

pub fn wrap14_host_func_async<A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13, A14, R>(
    &mut self,
    module: &str,
    name: &str,
    func: impl for<'a> Fn(Caller<'a>, A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13, A14) -> Box<dyn Future<Output = R> + 'a> + Send + Sync + 'static
) where
    A1: WasmTy,
    A2: WasmTy,
    A3: WasmTy,
    A4: WasmTy,
    A5: WasmTy,
    A6: WasmTy,
    A7: WasmTy,
    A8: WasmTy,
    A9: WasmTy,
    A10: WasmTy,
    A11: WasmTy,
    A12: WasmTy,
    A13: WasmTy,
    A14: WasmTy,
    R: WasmRet, 

Same as Config::wrap_host_func, except the closure asynchronously produces its result. For more information see the Func documentation.

Note: creating an engine will fail if an async host function is defined and async support is not enabled.

pub fn wrap15_host_func_async<A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13, A14, A15, R>(
    &mut self,
    module: &str,
    name: &str,
    func: impl for<'a> Fn(Caller<'a>, A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13, A14, A15) -> Box<dyn Future<Output = R> + 'a> + Send + Sync + 'static
) where
    A1: WasmTy,
    A2: WasmTy,
    A3: WasmTy,
    A4: WasmTy,
    A5: WasmTy,
    A6: WasmTy,
    A7: WasmTy,
    A8: WasmTy,
    A9: WasmTy,
    A10: WasmTy,
    A11: WasmTy,
    A12: WasmTy,
    A13: WasmTy,
    A14: WasmTy,
    A15: WasmTy,
    R: WasmRet, 

Same as Config::wrap_host_func, except the closure asynchronously produces its result. For more information see the Func documentation.

Note: creating an engine will fail if an async host function is defined and async support is not enabled.

pub fn wrap16_host_func_async<A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13, A14, A15, A16, R>(
    &mut self,
    module: &str,
    name: &str,
    func: impl for<'a> Fn(Caller<'a>, A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13, A14, A15, A16) -> Box<dyn Future<Output = R> + 'a> + Send + Sync + 'static
) where
    A1: WasmTy,
    A2: WasmTy,
    A3: WasmTy,
    A4: WasmTy,
    A5: WasmTy,
    A6: WasmTy,
    A7: WasmTy,
    A8: WasmTy,
    A9: WasmTy,
    A10: WasmTy,
    A11: WasmTy,
    A12: WasmTy,
    A13: WasmTy,
    A14: WasmTy,
    A15: WasmTy,
    A16: WasmTy,
    R: WasmRet, 

Same as Config::wrap_host_func, except the closure asynchronously produces its result. For more information see the Func documentation.

Note: creating an engine will fail if an async host function is defined and async support is not enabled.

Trait Implementations

impl Clone for Config

fn clone(&self) -> Config

Returns a copy of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for Config

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Default for Config

fn default() -> Config

Returns the “default value” for a type.