🛠️ [TASK] : WASM `Module::call_func` implementation parallelisation

[Mr-Leshiy]

Summary

Parallelise Module::call_func function implementation

Description

Run an internal implementation of the Module::call_func in the separate thread. Under the separate thread execution should be moved WASM Store initialisation, wasm module instantiation, and wasm function call.

    pub(crate) fn call_func<Args, Ret>(
        &mut self, name: &str, args: Args,
    ) -> Result<Ret, Box<dyn Error>>
    where
        Args: WasmParams,
        Ret: WasmResults,
    {
        self.context.use_for(name.to_string());
        std::thread::spawn(|| {
            let mut store = WasmStore::new(&self.engine, self.context.clone());
            let instance = self.pre_instance.instantiate(&mut store)?;
            let func = instance.get_typed_func(&mut store, name)?;
            Ok(func.call(&mut store, args)?)
        });
    }

[stevenj]

Based on my work with the WASM Component Model code generation, it may impact this work. We should probably look at integration with that first. WASM component model autogenerates the calls to the functions defined by the component model .wit files. See the example I have on calling using WASM Component model bindings.

[stevenj]

This needs to work by running the wasm module execute in a threadpool. Such that we can't have more wasm modules running than threads in the pool. The pool needs to be sized to the number of hardware threads in the computer -2. And a minimum of 1 (in the case of a computer with < 4 hardware threads).

[Mr-Leshiy]

@Mr-Leshiy need to update description