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.

Sign up for GitHub

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

Jump to bottom

Sync-Api doesn't work with multiple workers #23

Open
rchiodo opened this issue Oct 7, 2022 · 1 comment · May be fixed by #25
Open

Sync-Api doesn't work with multiple workers #23

rchiodo opened this issue Oct 7, 2022 · 1 comment · May be fixed by #25

Comments

@rchiodo
Copy link

rchiodo commented Oct 7, 2022

Suppose you have something like so:

Main Thread - Extension code
Worker 1 - Extension sub piece, which starts Worker 2
Worker 2 - Needs to use the sync api

Worker 2 cannot communicate with the Main Thread because its MessageChannel is only with Worker 1.

For CPython I have this exact situation when trying to run the debugger:

  • Main thread - Extension code
  • Worker 1 - Load of python.js
  • Worker 2 - Reader thread for debugger
  • Worker 3 - Writer thread for debugger

Worker 2 and 3 cannot send messages to the Main Thread.

  • Note: Emscripten (by default proxies) all FS (or socket) API calls to its main thread (worker 1 in this case) but that causes deadlock issues because the Atomics.wait in the sync-api block the main worker thread, therefore no other fs API calls can be handled while waiting. Took me a while to figure this out as most of it was working until Worker 3 tried to acquire a lock.
@rchiodo
Copy link
Author

rchiodo commented Oct 7, 2022 •
edited
Loading

I believe there's a solution to this, use a BroadcastChannel instead. (supported by node and web browsers).

Essentially every worker uses the BroadcastChannel instead. When sending messages, a target could be set, something like so:

{
    "dest": "main",
    "src": "worker-<threadid>"
}

Main thread would listen on the same broadcast channel and handle messages with "dest" : "main".
Worker threads would listen on the same broadcast channel and handle messages with "dest": "worker-<threadid>" where the thread id matches their own.

I believe that would let messages to go to and from an arbitrary worker to the main thread.

@rchiodo rchiodo linked a pull request Oct 10, 2022 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Use BroadcastChannel to support sub workers rchiodo/vscode-wasm
1 participant
@rchiodo