Ensure that JsValue isn't considered Send
#955
Merged
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
The `JsValue` type wraps a slab/heap of js objects which is managed by the wasm-bindgen shim, and everything here is not actually able to cross any thread boundaries. When wasm actually has threads, for example, each thread will have to have its own slab of objects generated by wasm-bindgen, and indices in one slab aren't valid in any other slabs. This is technically a breaking change because `JsValue` was previously `Send` and `Sync`, but I'm hoping that in practice this isn't actually a breaking change because nothing in wasm can be using threads which in theory shouldn't activate the `Send` and/or `Sync` bounds.
|
Well, it is a breaking change since it breaks the use of |
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.
The
JsValuetype wraps a slab/heap of js objects which is managed bythe wasm-bindgen shim, and everything here is not actually able to cross
any thread boundaries. When wasm actually has threads, for example, each
thread will have to have its own slab of objects generated by
wasm-bindgen, and indices in one slab aren't valid in any other slabs.
This is technically a breaking change because
JsValuewas previouslySendandSync, but I'm hoping that in practice this isn't actually abreaking change because nothing in wasm can be using threads which in
theory shouldn't activate the
Sendand/orSyncbounds.