Skip to content

Improve worker.js reliability #1820

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

Merged
merged 1 commit into from
Oct 17, 2019
Merged

Conversation

RReverser
Copy link
Member

While it doesn't happen right now in this particular example, lastPtr can be potentially overridden several times before the module is fully initialised.

Rather than having a boolean and a storage for one last argument, await a promise returned from wasm_bindgen itself in the new onmessage handler before executing actual command.

This way all the potential tasks will queue up naturally, wait for the initialisation, and then execute in a correct order.

While it doesn't happen right now in this particular example, `lastPtr` can be potentially overridden several times before the module is fully initialised.

Rather than having a boolean and a storage for one last argument, `await` a promise returned from `wasm_bindgen` itself in the new `onmessage` handler before executing actual command.

This way all the potential tasks will queue up naturally, wait for the initialisation, and then execute in a correct order.
@alexcrichton alexcrichton merged commit 46cbd19 into rustwasm:master Oct 17, 2019
@alexcrichton
Copy link
Contributor

Nice!

@RReverser
Copy link
Member Author

@alexcrichton Thanks for merging!

By the way, I found this published crate that pretty much extracted code from this example in a reusable fashion: https://crates.io/crates/web_worker.

I believe it's slightly out of sync and misses e.g. this worker.js, but otherwise it seems like quite a good idea to have a ready-to-use adapter for other people (like me) playing with multithreading in Rust + Wasm on their own.

I wonder if you'd want to coordinate with author and maybe help to make sure that their code is up-to-date, or make your own crate, and then switch this example to use it as a dependency?

@RReverser RReverser deleted the patch-2 branch October 17, 2019 22:38
@alexcrichton
Copy link
Contributor

Sure yeah, refactorings here seem reasonable to me! When I made this example afaik it was the only thing that could work, so it was the minimal thing I got working quickly. If there's more official ways to do it nowadays seems good!

@RReverser
Copy link
Member Author

@alexcrichton Oh, I don't think there are more official ways - as I said, that crate is basically an extracted version of your code here.

What I'm asking is if you'd want to make that crate the official way and sync your code to it, or publish your own crate for others to use.

@alexcrichton
Copy link
Contributor

I think we probably don't want to farm this out just yet, I don't have the time to maintain a separate crate and the threads spec is volatile enough I think we want to retain the ability to make changes here if necessary.

@RReverser
Copy link
Member Author

Fair enough. I think I'll publish some small wrapper myself then, but for now am hitting some Chromium bugs that need to be fixed before it's released.

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