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

Adjust examples and documentation to thread-aware start #3248

Merged
merged 1 commit into from
Feb 2, 2023

Conversation

daxpedda
Copy link
Collaborator

@daxpedda daxpedda commented Jan 19, 2023

We didn't adjust the examples and documentation after #3236.
This addresses that.

I honestly wasn't able to test the wasm-in-web-worker example because I couldn't get wasm-pack working.

Copy link
Collaborator

@Liamolucko Liamolucko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I completely missed this PR somehow. Thanks!

@Liamolucko Liamolucko merged commit 5f6e651 into rustwasm:main Feb 2, 2023
@Liamolucko
Copy link
Collaborator

Oops, I merged this too hastily, I just tested the wasm-in-web-worker example and it's hitting an unreachable. I'll try and debug it.

@daxpedda
Copy link
Collaborator Author

daxpedda commented Feb 2, 2023

I apologize for not actually being able to properly test this myself, I did try to get wasm-pack working but unfortunately I just can't figure out what the issue is.

Liamolucko added a commit to Liamolucko/wasm-bindgen that referenced this pull request Feb 2, 2023
The start function still gets called on every thread in that example because it doesn't actually use wasm multithreading; each thread's instance has it's own separate memory pool and is completely unaware of the other thread. So, attempting to switch it to use a regular start function caused the worker thread to spawn another one, which does likewise, quickly spiralling out of control.

It also ended up panicking because, thinking it was the main thread, the code was trying to access `window` inside of a worker.
alexcrichton pushed a commit that referenced this pull request Feb 2, 2023
The start function still gets called on every thread in that example because it doesn't actually use wasm multithreading; each thread's instance has it's own separate memory pool and is completely unaware of the other thread. So, attempting to switch it to use a regular start function caused the worker thread to spawn another one, which does likewise, quickly spiralling out of control.

It also ended up panicking because, thinking it was the main thread, the code was trying to access `window` inside of a worker.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants