forked from chemicstry/wasm_thread
-
Notifications
You must be signed in to change notification settings - Fork 1
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
postMessage
support
#1
Open
Twey
wants to merge
5
commits into
linera-io:main
Choose a base branch
from
Twey:post-message
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Module workers are now widely available, and assuming modules allows us to use `import.meta.url` to get the shim script URL directly rather than dynamically generating the script with a value injected. This results in a significantly more bundler-friendly experience, as well as letting us make use of `wasm_thread` in environments where dynamic code execution is not available, such as WebExtensions.
This allows us to run async code on the worker thread. A two-stage approach is used: first, a `Send` function is passed to the thread, which is executed to obtain a non-`Send` future. This supports the ‘work-dealing’ pattern in which the task is first moved to another thread, and then kept there whilst running.
Remove the spawn request functionality, since nested Web workers are now widely supported in browsers. This allows us to return a `Worker` directly that we can post messages to.
jvff
approved these changes
Nov 4, 2024
scope_data: Option<Arc<ScopeData>>, | ||
) -> std::io::Result<JoinInner<'scope, T>> | ||
) -> std::io::Result<(Thread, JoinInner<'scope, Fut::Output>)> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: would it make sense to return the JoinHandle
directly here?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In order to pass JavaScript objects like shared array buffers or WebAssembly modules into the thread, we need to be able to clone them across with the
structuredClone
algorithm, i.e. by usingpostMessage
.In a slightly hacky way, this PR:
es_modules
feature — for complicated bundler reasons it was a pain to get this working with modules, it would have required a different approach for non-modules, and module worker support is now widespreadasync
code in the spawned thread — this has to happen here because weclose()
the worker as soon as the function arrives, so the worker entrypoint has to be async-aware to not close the thread too soonWorker
object when we spawn as part of theJoinHandle
so we canpost_message
to it later