[CoreCLR] fibers on Windows - Wasmtime Async Compatibility

[martindevans]

Description

When C# is acting as the host for WASM execution (using wasmtime-dotnet), wasmtime will try to use fibers and fail.

Wasmtime supports async WASM execution, which can suspend running WASM code and resume it later.

Unfortunately the implementation seems to be incompatible with running inside dotnet.

Reproduction Steps

1. Clone this PR which I wrote for wasmtime-dotnet to add async support
2. Place a breakpoint inside an async callback
3. Run tests
4. Observe failures

Expected behavior

Wasmtime async should work in dotnet.

Whether this should involve a change to dotnet or a change to wasmtime I'm not sure. My motivation here is really just like to draw attention to this incompatibility and to get some input from dotnet developers on the PR.

Actual behavior

Tests fail with System.Runtime.InteropServices.SEHException when hitting a breakpoint.

According to this comment it can sometimes crash with "Fatal error. Internal CLR error." or "AccessViolationException".

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Wasmtime supports async WASM execution, which can suspend running WASM code and resume it later.

Unfortunately the implementation seems to be incompatible with dotnet.

Reproduction Steps

1. Clone this PR which I wrote for wasmtime-dotnet to add async support
2. Place a breakpoint inside an async callback
3. Run tests
4. Observe failures

Expected behavior

Wasmtime async should work in dotnet.

Whether this should involve a change to dotnet or a change to wasmtime I'm not sure. My motivation here is really just like to draw attention to this incompatibility and to get some input from dotnet developers on the PR.

Actual behavior

Tests fail with System.Runtime.InteropServices.SEHException when hitting a breakpoint.

According to this comment it can sometimes crash with "Fatal error. Internal CLR error." or "AccessViolationException".

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

Author:	martindevans
Assignees:	-
Labels:	arch-wasm, untriaged, area-VM-meta-mono
Milestone:	-

[martindevans]

I would guess arch-wasm probably isn't the right tag, since this is about using wasm within dotnet rather than dotnet within wasm.

[vcsjones]

I would guess arch-wasm probably isn't the right tag

Yeah, I noticed - but it's probably the best way to get eyes on the issue from the right folks at this point in time - they can re-assign the arch if they feel it is incorrectly assigned.

[lewing]

More work is happening here https://github.com/dicej/isyswasfa

[pavelsavara]

I believe that we have initial implementation for this now for WASIp2.

See
https://github.com/dotnet/runtime/blob/main/src/mono/sample/wasi/http-p2/Program.cs

This will improve with WASIp3

[martindevans]

@pavelsavara I don't think that resolves this issue. That looks like it's for async support when compiling C# to WASM. But this issue about the other case - when C# is acting as the host for WASM execution (using wasmtime-dotnet).

In this case the async features of wasmtime cannot be used because they are built with fibers, which are incompatible with dotnet:

The .NET threading model does not support fibers. You should not call into any unmanaged function that is implemented by using fibers. Such calls may result in a crash of the .NET runtime.
source.

[pavelsavara]

Ah, so this is not about WASI at all. This is about CoreCLR vs wasmtime on windows

[pavelsavara]

I think that somebody from CoreCLR needs to close this as won't fix.

[dotnet-policy-service]

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

[martindevans]

According to this comment from one of the Wasmtime developers there's no alternative way to implement stack switching on Windows others than fibers. If there's no chance of dotnet gaining support for using fibers is there some other dotnet compatible alternative wasmtime could switch to?