Async API

[Andoryuuta]

Hello!

I'm trying to figure out the best way to wrap the async support that was added to the wasmtime C API. A good portion of this looks easy to wrap as methods in the existing C++ classes. However, I'm struggling to think of a good interface for wrapping the new functions that return call futures and require output pointers to live as long as the future itself.

In specific, these three functions:

WASM_API_EXTERN wasmtime_call_future_t *wasmtime_func_call_async(
    wasmtime_context_t *context, const wasmtime_func_t *func,
    const wasmtime_val_t *args, size_t nargs, wasmtime_val_t *results,
    size_t nresults, wasm_trap_t **trap_ret, wasmtime_error_t **error_ret);

WASM_API_EXTERN wasmtime_call_future_t *wasmtime_linker_instantiate_async(
    const wasmtime_linker_t *linker, wasmtime_context_t *store,
    const wasmtime_module_t *module, wasmtime_instance_t *instance,
    wasm_trap_t **trap_ret, wasmtime_error_t **error_ret);

WASM_API_EXTERN wasmtime_call_future_t *wasmtime_instance_pre_instantiate_async(
    const wasmtime_instance_pre_t *instance_pre, wasmtime_context_t *store,
    wasmtime_instance_t *instance, wasm_trap_t **trap_ret,
    wasmtime_error_t **error_ret);

In order to not require users of the wasmtime-cpp API to hold types from the C API, I think we will have to introduce a class for each of these calls holding the input/output parameters that need to be kept alive together.

Any thoughts/opinion regarding this? I just wanted to open a general discussion issue on the topic before I do too much.

[alexcrichton]

I'm definitely no C++ expert myself so I alas don't know how best to model asynchronous computations in C++. From what little I know of other codebases lifetimes are a big no-no and are avoided at all times where async computations are always "owned things" that don't borrow anything else, mainly for fear of getting it wrong otherwise. I don't know if that's common practice though.

[alexcrichton]

I'm going to close this as this repository has now migrated into the wasmtime repository itself -- bytecodealliance/wasmtime#10582, and while this issue is still applicable I think it's best to reopen on upstream.