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] GC, threadpool and some JS interop improvements #86759

Merged
merged 20 commits into from
Jun 12, 2023

Conversation

pavelsavara
Copy link
Member

@pavelsavara pavelsavara commented May 25, 2023

This makes GC, threadpool and some JS interop scenarios work on the mini sample

Changes

  • JSSynchronizationContext - could be installed on multiple threads
    • has target thread, instead of just main thread
    • new InstallWebWorkerInterop and UninstallWebWorkerInterop
    • JSSynchronizationContext is automatically installed on the main thread
    • new mono_target_thread_schedule_background_job helps to implement that
    • external_eventloop and thread_id private fields of Thread are accessed via reflection. I don't know about better way right now.
  • new System.Runtime.InteropServices.JavaScript.WebWorker for starting threads dedicated to JS interop
    • Run method accepts synchronous Action.
      • enables calling synchronous JSImport/JSExport
      • since you can't (async) import JS module, you could only call runtime code which is already loaded into the webworker
      • maybe we would not have this signature as public API as it's not very useful to end user
    • RunAsync accepts Func<Task> and enables JS interop as well as async JSImport/JSExport.
      • this is necessary for any JSHost.ImportAsync
      • for any Http or WS client
      • callback needs to keep the returned Task unresolved while working with JS/promises/events/network
    • user would be responsible for cleanup of the JS global web worker state, as the same web worker could be re-used later.
    • the idea is that WebWorker is un-managed resource
    • drafted forceDisposeProxies which is called at the end of WebWorker run

Fixes & tests

  • added MONO_ENTER_GC_UNSAFE/MONO_EXIT_GC_UNSAFE into lifo-semaphore.c callbacks
  • added MONO_ENTER_GC_UNSAFE/MONO_EXIT_GC_UNSAFE into mono_wasm_invoke_method_bound
  • added mono_threads_wasm_on_thread_detached callback for easier tracking of web workers
  • added set_thread_info which creates function globalThis.monoThreadInfo on the worker. It's easy to look at in the browser dev tools. Just in debug build of the runtime.
  • use Module.safeSetTimeout for jobs
  • GC + timers mini-test in the browser-threads-minimal
  • native thread ID as prefix for worker JS logging
  • fixed SystemNative_GetCpuUtilization

Next

  • WebWorker API is just early sketch. Do we want to make it IDisposable instance instead ?
  • threads are detached slowly and so the sample needs at least 6 web workers in the pool.
  • this doesn't yet run unit tests very well
  • perhaps we could asynchronously allocate more web workers into emscripten pool
  • we could also allocate new web worker for each WebWorker.Run, maybe with a flag parameter
  • finish implementation of forceDisposeProxies

@pavelsavara pavelsavara added arch-wasm WebAssembly architecture area-System.Threading labels May 25, 2023
@pavelsavara pavelsavara added this to the 8.0.0 milestone May 25, 2023
@pavelsavara pavelsavara self-assigned this May 25, 2023
@ghost
Copy link

ghost commented May 25, 2023

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

Issue Details

work in progress

Author: pavelsavara
Assignees: pavelsavara
Labels:

arch-wasm, area-System.Threading

Milestone: 8.0.0

@pavelsavara pavelsavara force-pushed the browser_threads_next branch 2 times, most recently from d6d63df to 114268b Compare May 29, 2023 21:24
@pavelsavara pavelsavara changed the title [draft][browser] thread experiments [browser][MT] GC, threadpool and some JS interop improvements May 31, 2023
@pavelsavara pavelsavara marked this pull request as ready for review May 31, 2023 16:51
@pavelsavara
Copy link
Member Author

/azp run runtime-wasm

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@lewing

This comment was marked as resolved.

@radical

This comment was marked as resolved.

@pavelsavara
Copy link
Member Author

/azp run runtime-wasm

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@pavelsavara
Copy link
Member Author

I created #87314 and #87315 for MT debugger failure on CI

@pavelsavara
Copy link
Member Author

/azp run runtime-wasm

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@pavelsavara
Copy link
Member Author

/azp run runtime-wasm

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@pavelsavara
Copy link
Member Author

/azp run runtime-wasm

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@pavelsavara
Copy link
Member Author

/azp run runtime-wasm

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@pavelsavara
Copy link
Member Author

CI failures are #87414 and #87423

@pavelsavara pavelsavara merged commit 6c3a197 into dotnet:main Jun 12, 2023
@ghost ghost locked as resolved and limited conversation to collaborators Jul 13, 2023
@pavelsavara pavelsavara deleted the browser_threads_next branch September 2, 2024 15:30
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
arch-wasm WebAssembly architecture area-System.Threading
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants