There are two cases where Wasmtime diverges from what's currently in the CM spec repo when non-async-typed functions are involved. Filing together b/c maybe they tickle some of the same code bits:
In the first case, captured in test/async/no-sibling-resume-during-sync-call.wast (currently in a branch): while a synchronous function is running, the scheduler isn't supposed to switch to threads in other component instances. (Doing so would allow surprise-reentrance during a sync call, which the above WAST actually exhibits.) This WAST tests hits this case first using only 0.3.0 features (in $Tester1) and then using cooperative threads (in $Tester2).
In the second case, captured in test/async/sync-call-async-with-ready-thread.wast (also currently in a branch): the spec currently says that if you synchronously call an async-typed function, whether it traps or not does not depend on the current thread's task's function type (since you can easily switch between threads of different tasks while executing a synchronous call, which is what the above WAST does). Instead, what matters is: if you block (for any reason, not just sync-calling an async import) during a synchronous call before returning a value: if there are no other threads ready to run in the same instance, you trap. Currently, Wasmtime has an eager trap based on the current thread's task's function type, but if you switch to another thread (which is part of an async task) you get the spec-defined trap-if-cant-switch behavior. This is shown in the WAST using only 0.3.0 features (in $Tester1) and then using cooperative threads (in $Tester2).
There are two cases where Wasmtime diverges from what's currently in the CM spec repo when non-
async-typed functions are involved. Filing together b/c maybe they tickle some of the same code bits:In the first case, captured in test/async/no-sibling-resume-during-sync-call.wast (currently in a branch): while a synchronous function is running, the scheduler isn't supposed to switch to threads in other component instances. (Doing so would allow surprise-reentrance during a sync call, which the above WAST actually exhibits.) This WAST tests hits this case first using only 0.3.0 features (in
$Tester1) and then using cooperative threads (in$Tester2).In the second case, captured in test/async/sync-call-async-with-ready-thread.wast (also currently in a branch): the spec currently says that if you synchronously call an
async-typed function, whether it traps or not does not depend on the current thread's task's function type (since you can easily switch between threads of different tasks while executing a synchronous call, which is what the above WAST does). Instead, what matters is: if you block (for any reason, not just sync-calling anasyncimport) during a synchronous call before returning a value: if there are no other threads ready to run in the same instance, you trap. Currently, Wasmtime has an eager trap based on the current thread's task's function type, but if you switch to another thread (which is part of anasynctask) you get the spec-defined trap-if-cant-switch behavior. This is shown in the WAST using only 0.3.0 features (in$Tester1) and then using cooperative threads (in$Tester2).