Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[browser][MT] Handling blocking wait #99833

Merged
merged 13 commits into from
Apr 4, 2024

Conversation

pavelsavara
Copy link
Member

@pavelsavara pavelsavara commented Mar 15, 2024

  • simplify configuration of MT handling of blocking .Wait
    • removed MainThreadingMode and JSThreadInteropMode configuration
  • new Thread.WarnOnBlockingWaitOnJSInteropThread
  • MT unit tests now use ThrowWhenBlockingWait mode

JSThreadBlockingMode now could have following values

PreventSynchronousJSExport - default

  • Prevents synchronous JSExport from being called from JavaScript code in UI thread.
  • On JSWebWorker synchronous JSExport always works.
  • On JSWebWorker blocking .Wait always warns.
  • This is the default mode.

ThrowWhenBlockingWait

  • Allows synchronous JSExport to be called from JavaScript code also in UI thread.
  • Inside of that call blocking .Wait throws PNSE.
  • Inside of that call nested call back to synchronous JSImport throws PNSE (because it would deadlock otherwise in 100% cases).
  • On JSWebWorker synchronous JSExport always works.
  • On JSWebWorker blocking .Wait always throws PNSE.

WarnWhenBlockingWait

  • Allows synchronous JSExport to be called from JavaScript code also in UI thread.
  • Inside of that call blocking .Wait warns.
  • Inside of that call nested call back to synchronous JSImport throws PNSE (because it would deadlock otherwise in 100% cases).
  • On JSWebWorker synchronous JSExport always works.
  • On JSWebWorker blocking .Wait always warns.

DangerousAllowBlockingWait

  • Allows synchronous JSExport to be called from JavaScript code, and allows managed code to use blocking .Wait
  • .Wait on Promise/Task chains could lead to deadlock because JS event loop is not processed and it can't resolve JS promises.
  • This mode is dangerous and not supported.
  • Allows synchronous JSExport to be called from JavaScript code also in main thread.
  • Inside of that call nested call back to synchronous JSImport throws PNSE (because it would deadlock otherwise in 100% cases).

Contributes to #76958
Contributes to #98652
Contributes to #99951

Fixes #98804
Fixes #97914
Fixes #44622

More scenarios: #93603 (comment)

@pavelsavara pavelsavara added arch-wasm WebAssembly architecture area-VM-threading-mono os-browser Browser variant of arch-wasm labels Mar 15, 2024
@pavelsavara pavelsavara added this to the 9.0.0 milestone Mar 15, 2024
@pavelsavara pavelsavara self-assigned this Mar 15, 2024
Copy link
Contributor

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

# Conflicts:
#	src/mono/browser/runtime/loader/config.ts
#	src/mono/browser/runtime/managed-exports.ts
#	src/mono/browser/runtime/types/internal.ts
@pavelsavara pavelsavara requested a review from maraf March 27, 2024 17:58
@pavelsavara pavelsavara marked this pull request as ready for review March 27, 2024 17:58
@pavelsavara
Copy link
Member Author

/azp run runtime-wasm

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@pavelsavara
Copy link
Member Author

All the CI failures are #99888

@pavelsavara pavelsavara merged commit ffb2578 into dotnet:main Apr 4, 2024
159 of 162 checks passed
@pavelsavara pavelsavara deleted the browser_mt_pnse branch April 4, 2024 11:41
matouskozak pushed a commit to matouskozak/runtime that referenced this pull request Apr 30, 2024
@github-actions github-actions bot locked and limited conversation to collaborators May 5, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
arch-wasm WebAssembly architecture area-VM-threading-mono os-browser Browser variant of arch-wasm
Projects
None yet
2 participants