c-api: Expose async_stack_size configuration

[guregu]

Adds wasm_config_async_stack_size_set to C API. Also updates the stack-related comments in config.h to match the latest Rust ones.

Motivation: I want to set the stack size in wasmtime-go, but max_wasm_stack is limited by async_stack_size, so we need to set this too.

[github-actions]

Subscribe to Label Action

cc @peterhuene

Details

This issue or pull request has been labeled: "wasmtime:c-api"

Thus the following users have been cc'd because of the following labels:

• peterhuene: wasmtime:c-api

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[alexcrichton]

Thanks! Can you elaborate a bit more on how this is used though? Async isn't exposed through the C API so in theory this configuration option shouldn't do anything in the C API, but if it's causing issues then that's a bug where when async is turned off it shouldn't be consulted.

[guregu]

@alexcrichton I agree that's it's more likely a bug (or maybe misconfiguration?) somewhere else.

Basically, if I try to set the stack size to 8MB in wasmtime-go it will fail with this message:

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: max_wasm_stack size cannot exceed the async_stack_size', crates/c-api/src/engine.rs:33:38
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 5
SIGABRT: abort
PC=0x198cf4724 m=0 sigcode=0
signal arrived during cgo execution

So I figured exposing this knob could work around that. But perhaps the issue lies elsewhere 🤔

Would be happy to move this to wasmtime-go issue if that is the case!

[guregu]

@alexcrichton I made an issue here for the wasmtime-go problem: bytecodealliance/wasmtime-go#182. Please feel free to close this if it's not needed after all!

[alexcrichton]

Oh no you're all good, I think that this is still a bug in Wasmtime, so this is the right place to fix it. I don't think there's a way to work around that from wasmtime-go right now.

I think the fix though is to update this condition to additionally check async_support because if that's disabled then there's no need to test anything about the async stack size, which I think would fix your use case because async_support is false for the C API.

[guregu]

Aha, that makes sense! I will take that approach in a new PR. Thank you for the help 🙏

[jameysharp]

I think that's a good fix to apply. In addition it occurs to me that perhaps the C API should build the wasmtime crate with the async feature disabled, since it can't make use of the async support anyway. That would have avoided this bug because the if statement in question wouldn't have been compiled in at all.

[guregu]

New PR that takes the suggested approach: #6771