Split PortableThreadPool.WorkerThread start and loop body #84490
Conversation
For browser-wasm we will need to start the worker thread in a special way, and use callbacks to run the loop body. Current PR is just refactoring existing code. No functional change.
|
Tagging subscribers to this area: @mangod9 Issue DetailsThis is Part 1 of #84489 - landing support for async JS interop on threadpool threads in multi-threaded WebAssembly. We will need to start the threadpool worker threads on the browser in a special way, such that they can exit back to the JS event loop, and use callbacks to run the worker loop body. The current PR splits into a separate file the logic for starting threadpool worker threads, and the outer loop that waits for the semaphore that signals that work is available for the worker. The loop body (to be shared with the callback-based approach in a future PR) remains in Current PR is just refactoring existing code. No functional change.
|
|
For reviewers: I recommend turning on "hide whitespace" for this PR on GitHub
|
|
@kouvel could you take a look |
| threadAdjustmentLock.Release(); | ||
| } | ||
| // if we get here new work came in and we're going to keep running | ||
| return false; |
There was a problem hiding this comment.
Could just return false instead of the break statement above
...es/System.Private.CoreLib/src/System/Threading/PortableThreadPool.WorkerThread.NonBrowser.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.WorkerThread.cs
Outdated
Show resolved
Hide resolved
|
Failure is #84979 |
ghost
locked as resolved and limited conversation to collaborators
This is Part 1 of #84489 - landing support for async JS interop on threadpool threads in multi-threaded WebAssembly.
We will need to start the threadpool worker threads on the browser in a special way, such that they can exit back to the JS event loop, and use callbacks to run the worker loop body.
The current PR splits into a separate file the logic for starting threadpool worker threads, and the outer loop that waits for the semaphore that signals that work is available for the worker. The loop body (to be shared with the callback-based approach in a future PR) remains in
PortableThreadPool.WorkerThread.csas several new toplevel functions.Current PR is just refactoring existing code. No functional change.