Stream: git-wasmtime

Topic: wasmtime / PR #12043 trap on blocking call in sync task b...

Wasmtime GitHub notifications bot (Nov 18 2025 at 18:30):

dicej opened PR #12043 from dicej:trap-blocking-in-sync-tasks to bytecodealliance:main:

This implements a spec change (PR pending) such that tasks created for calls to synchronous exports may not call potentially-blocking imports or return wait or poll callback codes prior to returning a value. Specifically, the following are prohibited in that scenario:

• returning callback-code.{wait,poll}
• sync calling async import
• sync calling subtask.cancel
• sync calling {stream,future}.{read,write}
• sync calling {stream,future}.cancel-{read,write}
• calling waitable-set.{wait,poll}
• calling thread.suspend

This breaks a number of tests, which will be addressed in follow-up commits:

• The {tcp,udp}-socket.bind implementation in wasmtime-wasi is implemented using Linker::func_wrap_concurrent and thus assumed to be async, whereas the WIT interface says they're sync, leading to a type mismatch error at runtime. Alex and I have discussed this and have a general plan to address it.

• A number of tests in the tests/component-model submodule that points to the spec repo are failing. Those will presumably be fixed as part of the upcoming spec PR (although some could be due to bugs in this implementation, in which case I'll fix them).

• A number of tests in tests/misc_testsuite are failing. I'll address those in a follow-up commit.

<!--
Please make sure you include the following information:

• If this work has been discussed elsewhere, please include a link to that
  conversation. If it was discussed in an issue, just mention "issue #...".

• Explain why this change is needed. If the details are in an issue already,
  this can be brief.

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

Wasmtime GitHub notifications bot (Nov 18 2025 at 18:30):

dicej requested alexcrichton for a review on PR #12043.

Wasmtime GitHub notifications bot (Nov 18 2025 at 18:33):

dicej updated PR #12043.

Wasmtime GitHub notifications bot (Nov 18 2025 at 18:33):

dicej edited PR #12043:

This implements a spec change (PR pending) such that tasks created for calls to synchronous exports may not call potentially-blocking imports or return wait or poll callback codes prior to returning a value. Specifically, the following are prohibited in that scenario:

• returning callback-code.{wait,poll}
• sync calling an async import
• sync calling subtask.cancel
• sync calling {stream,future}.{read,write}
• sync calling {stream,future}.cancel-{read,write}
• calling waitable-set.{wait,poll}
• calling thread.suspend

This breaks a number of tests, which will be addressed in follow-up commits:

• The {tcp,udp}-socket.bind implementation in wasmtime-wasi is implemented using Linker::func_wrap_concurrent and thus assumed to be async, whereas the WIT interface says they're sync, leading to a type mismatch error at runtime. Alex and I have discussed this and have a general plan to address it.

• A number of tests in the tests/component-model submodule that points to the spec repo are failing. Those will presumably be fixed as part of the upcoming spec PR (although some could be due to bugs in this implementation, in which case I'll fix them).

• A number of tests in tests/misc_testsuite are failing. I'll address those in a follow-up commit.

<!--
Please make sure you include the following information:

• If this work has been discussed elsewhere, please include a link to that
  conversation. If it was discussed in an issue, just mention "issue #...".

• Explain why this change is needed. If the details are in an issue already,
  this can be brief.

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

Wasmtime GitHub notifications bot (Nov 18 2025 at 19:19):

dicej updated PR #12043.

Wasmtime GitHub notifications bot (Nov 18 2025 at 19:20):

dicej edited PR #12043:

This implements a spec change (PR pending) such that tasks created for calls to synchronous exports may not call potentially-blocking imports or return wait or poll callback codes prior to returning a value. Specifically, the following are prohibited in that scenario:

• returning callback-code.{wait,poll}
• sync calling an async import
• sync calling subtask.cancel
• sync calling {stream,future}.{read,write}
• sync calling {stream,future}.cancel-{read,write}
• calling waitable-set.{wait,poll}
• calling thread.suspend

This breaks a number of tests, which will be addressed in follow-up commits:

• The {tcp,udp}-socket.bind implementation in wasmtime-wasi is implemented using Linker::func_wrap_concurrent and thus assumed to be async, whereas the WIT interface says they're sync, leading to a type mismatch error at runtime. Alex and I have discussed this and have a general plan to address it.

• A number of tests in the tests/component-model submodule that points to the spec repo are failing. Those will presumably be fixed as part of the upcoming spec PR (although some could be due to bugs in this implementation, in which case I'll fix them).

• A number of tests in tests/misc_testsuite are failing. I'll address those in a follow-up commit.

<!--
Please make sure you include the following information:

• If this work has been discussed elsewhere, please include a link to that
  conversation. If it was discussed in an issue, just mention "issue #...".

• Explain why this change is needed. If the details are in an issue already,
  this can be brief.

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

Wasmtime GitHub notifications bot (Nov 24 2025 at 17:02):

alexcrichton commented on PR #12043:

Talked about this with @dicej today, current blockers are:

• Waiting on upstream PR to the spec to have an official point-of-reference
• Current upstream tests are failing, and upstream spec PR likely to update.
• Tests for "full matrix of trapping behavior" still needed

Wasmtime GitHub notifications bot (Nov 24 2025 at 18:56):

dicej commented on PR #12043:

Regarding the {tcp,udp}-socket.bind test failures, I've opened https://github.com/WebAssembly/wasi-sockets/issues/144.

Eventually, we'll want a proper way for host functions to "cheat" and block the whole guest _without_ monopolizing the Store, as well, but no need to block this PR on that.

Wasmtime GitHub notifications bot (Nov 24 2025 at 20:50):

alexcrichton commented on PR #12043:

New thought: I think we're going to be required to implement "component-model-sync function can do async things on the host" in Wasmtime. Ignoring p3 for a moment, that's exactly how all async works in WASIp2. All WASIp2 functions are "sync" functions which leverage host superpowers to suspend the guest, and we can't break WASIp2, so I don't think that "just solve tcp/udp for wasip3" is a viable solution after all.

Wasmtime GitHub notifications bot (Nov 24 2025 at 21:06):

dicej updated PR #12043.

Wasmtime GitHub notifications bot (Nov 24 2025 at 21:53):

dicej commented on PR #12043:

All WASIp2 functions are "sync" functions which leverage host superpowers to suspend the guest, and we can't break WASIp2

Agreed, but I don't see how that's relevant to this PR. Sync-typed exports are still permitted to call sync-typed imports, and wasmtime-wasi's p2 implementation uses Linker::func_wrap_async, which defines a sync-typed host function, so nothing in this PR or the proposed spec changes will break wasmtime-wasi's p2 implementation.

Certainly we'll need to confront p2 head-on once we remove or replace Linker::func_wrap_async, but we're not doing that here.

Wasmtime GitHub notifications bot (Nov 24 2025 at 22:11):

alexcrichton commented on PR #12043:

Er right, yes, wires crossed again. That means though that https://github.com/bytecodealliance/wasmtime/pull/12085 is possible which "fixes" tcp/udp.

Wasmtime GitHub notifications bot (Nov 24 2025 at 23:04):

dicej updated PR #12043.

Wasmtime GitHub notifications bot (Nov 24 2025 at 23:06):

dicej edited PR #12043:

This implements a spec change (PR pending) such that tasks created for calls to synchronous exports may not call potentially-blocking imports or return wait or poll callback codes prior to returning a value. Specifically, the following are prohibited in that scenario:

• returning callback-code.{wait,poll}
• sync calling an async import
• sync calling subtask.cancel
• sync calling {stream,future}.{read,write}
• sync calling {stream,future}.cancel-{read,write}
• calling waitable-set.{wait,poll}
• calling thread.suspend

This breaks a number of tests, which will be addressed in follow-up commits:

• The {tcp,udp}-socket.bind implementation in wasmtime-wasi is implemented using Linker::func_wrap_concurrent and thus assumed to be async, whereas the WIT interface says they're sync, leading to a type mismatch error at runtime. Alex and I have discussed this and have a general plan to address it. EDIT: addressed by https://github.com/bytecodealliance/wasmtime/pull/12085

• A number of tests in the tests/component-model submodule that points to the spec repo are failing. Those will presumably be fixed as part of the upcoming spec PR (although some could be due to bugs in this implementation, in which case I'll fix them).

• A number of tests in tests/misc_testsuite are failing. I'll address those in a follow-up commit.

<!--
Please make sure you include the following information:

• If this work has been discussed elsewhere, please include a link to that
  conversation. If it was discussed in an issue, just mention "issue #...".

• Explain why this change is needed. If the details are in an issue already,
  this can be brief.

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

Wasmtime GitHub notifications bot (Nov 24 2025 at 23:09):

dicej updated PR #12043.

Wasmtime GitHub notifications bot (Nov 25 2025 at 00:25):

dicej updated PR #12043.

Wasmtime GitHub notifications bot (Nov 25 2025 at 15:13):

dicej commented on PR #12043:

Some of the WAST tests are hanging and/or busy looping. I'll investigate this morning.

Wasmtime GitHub notifications bot (Nov 25 2025 at 16:44):

dicej updated PR #12043.

Wasmtime GitHub notifications bot (Nov 25 2025 at 17:06):

dicej has marked PR #12043 as ready for review.

Wasmtime GitHub notifications bot (Nov 25 2025 at 17:06):

dicej requested wasmtime-core-reviewers for a review on PR #12043.

Wasmtime GitHub notifications bot (Nov 25 2025 at 17:07):

dicej commented on PR #12043:

CI is green now; I'm temporarily pointing the tests/component-model submodule at https://github.com/WebAssembly/component-model/pull/577 until that PR is merged.

Wasmtime GitHub notifications bot (Nov 25 2025 at 17:09):

dicej commented on PR #12043:

I believe we're just waiting on a spec PR (hopefully accompanied by WAST tests covering the changes) at this point.

Wasmtime GitHub notifications bot (Dec 01 2025 at 17:47):

dicej edited PR #12043:

This implements a spec change (PR pending) such that tasks created for calls to synchronous exports may not call potentially-blocking imports or return wait or poll callback codes prior to returning a value. Specifically, the following are prohibited in that scenario:

• returning callback-code.{wait,poll}
• sync calling an async import
• sync calling subtask.cancel
• sync calling {stream,future}.{read,write}
• sync calling {stream,future}.cancel-{read,write}
• calling waitable-set.{wait,poll}
• calling thread.suspend

This breaks a number of tests, which will be addressed in follow-up commits:

• The {tcp,udp}-socket.bind implementation in wasmtime-wasi is implemented using Linker::func_wrap_concurrent and thus assumed to be async, whereas the WIT interface says they're sync, leading to a type mismatch error at runtime. Alex and I have discussed this and have a general plan to address it. EDIT: addressed by https://github.com/bytecodealliance/wasmtime/pull/12085

• A number of tests in the tests/component-model submodule that points to the spec repo are failing. Those will presumably be fixed as part of the upcoming spec PR (although some could be due to bugs in this implementation, in which case I'll fix them). EDIT: addressed by https://github.com/WebAssembly/component-model/pull/577

• A number of tests in tests/misc_testsuite are failing. I'll address those in a follow-up commit.

<!--
Please make sure you include the following information:

• If this work has been discussed elsewhere, please include a link to that
  conversation. If it was discussed in an issue, just mention "issue #...".

• Explain why this change is needed. If the details are in an issue already,
  this can be brief.

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

Wasmtime GitHub notifications bot (Dec 01 2025 at 22:28):

dicej updated PR #12043.

Wasmtime GitHub notifications bot (Dec 01 2025 at 23:17):

dicej updated PR #12043.

Wasmtime GitHub notifications bot (Dec 02 2025 at 14:27):

pannous commented on PR #12043:

the following are prohibited in that scenario:
> sync calling an async import

sorry again how is that not function coloring?

Wasmtime GitHub notifications bot (Dec 02 2025 at 14:58):

dicej requested wasmtime-compiler-reviewers for a review on PR #12043.

Wasmtime GitHub notifications bot (Dec 02 2025 at 14:58):

dicej updated PR #12043.

Wasmtime GitHub notifications bot (Dec 03 2025 at 00:07):

alexcrichton commented on PR #12043:

@pannous if you have technical concerns about this change, mind bringing it up on https://github.com/WebAssembly/component-model/pull/578? That'll be a better forum for discussing the design than here

Wasmtime GitHub notifications bot (Dec 04 2025 at 15:36):

alexcrichton commented on PR #12043:

@dicej did you have anything else you wanted to sort out with this or is it ready to go?

Wasmtime GitHub notifications bot (Dec 04 2025 at 18:00):

dicej commented on PR #12043:

@dicej did you have anything else you wanted to sort out with this or is it ready to go?

Currently the tests/component-model submodule is pointing at my PR branch, and we can't point it to the main branch until https://github.com/WebAssembly/component-model/pull/578 is merged. If we're ok with temporarily pointing at the PR branch, we can merge this; otherwise, we need to wait.

Wasmtime GitHub notifications bot (Dec 05 2025 at 16:06):

alexcrichton commented on PR #12043:

Could this ignore the upstream tests temporarily and/or vendor working copies of them?

Behavior-wise though there's nothing more you're looking to add here?

Wasmtime GitHub notifications bot (Dec 05 2025 at 16:21):

alexcrichton submitted PR review:

Two extra thoughts in addition to the ones below:

• Could an assert! be done in a single "core" location that suspension happens that the task is allowed to block? That would be a final check that we did indeed sprinkle all the checks correctly.
• We'll definitely want a test, in repo, that traps happen as opposed to just updating all existing tests to not trap. I believe Luke has one upstream, but for landing this ahead of the upstream PR could this vendor the test in this repo to ensure we're running it here?

Wasmtime GitHub notifications bot (Dec 05 2025 at 16:21):

alexcrichton created PR review comment:

Can you leave a comment on checks like this to indicate what the trap/check represents?

Wasmtime GitHub notifications bot (Dec 05 2025 at 16:21):

alexcrichton created PR review comment:

This'll want to get filled out I believe

Wasmtime GitHub notifications bot (Dec 05 2025 at 16:21):

alexcrichton created PR review comment:

Similar to host.rs, mind leaving a comment on these checks throughout this file explaining what's going on?

Wasmtime GitHub notifications bot (Dec 05 2025 at 16:21):

alexcrichton created PR review comment:

Could this be plumbed through with S as a type parameter rather than an extra argument to follow the same idioms of the other constructors in this file?

Wasmtime GitHub notifications bot (Dec 05 2025 at 17:21):

dicej commented on PR #12043:

Could this ignore the upstream tests temporarily and/or vendor working copies of them?

Yeah; I'll switch the submodule back and temporarily skip the offending tests.

Behavior-wise though there's nothing more you're looking to add here?

Correct; nothing left behavior-wise.

Wasmtime GitHub notifications bot (Dec 05 2025 at 17:24):

dicej commented on PR #12043:

• Could an assert! be done in a single "core" location that suspension happens that the task is allowed to block? That would be a final check that we did indeed sprinkle all the checks correctly.

I'll look into that.

• We'll definitely want a test, in repo, that traps happen as opposed to just updating all existing tests to not trap. I believe Luke has one upstream, but for landing this ahead of the upstream PR could this vendor the test in this repo to ensure we're running it here?

Yup, I'll just copy the test from his PR into e.g. misc_testsuite.

Wasmtime GitHub notifications bot (Dec 05 2025 at 21:05):

alexcrichton submitted PR review:

Oh meant to do this too

Last updated: Dec 06 2025 at 06:05 UTC