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

on web-sys types not being Send and Sync #2753

Closed
d-e-s-o opened this issue Dec 31, 2021 · 2 comments
Closed

on web-sys types not being Send and Sync #2753

d-e-s-o opened this issue Dec 31, 2021 · 2 comments
Labels

Comments

@d-e-s-o
Copy link
Contributor

d-e-s-o commented Dec 31, 2021

Representative of presumably (many?) more types, I'd like to understand why Window does not implement Send and Sync. I understand that it apparently embeds a js_sys::Object which contains a wasm_bindgen::JsValue which in turn has a PhantomData<*mut u8>, which causes everything using it to be !Send and !Sync by default. What I'd like to understand is whether lack of implementation of these traits is by design or an oversight.

I haven't found any discussion of this topic anywhere, so if you have any pointers kindly forward them.

Perhaps not implementing Send is not a big deal in a truly web world, but it has huge trickle down effects on downstream crates that cross this boundary (because web-sys, for example, is so low in the stack). E.g., I have a crate that provides functionality natively using native APIs or, when compiled for wasm32-unknown-unknown, using web APIs.
The native stuff is pretty much all Send, including futures created etc. But once the web backend is used, nothing is anymore. Now I have to sprinkle compile time conditions in dozens of places, which renders the code borderline unmaintainable and is just a humongous source of complexity. And it just doesn't get any better higher up the stack because these traits are so infectious.

Hence, can someone please

  • clarify whether this is an oversight or whether there has been discussion on the topic
  • if there are insurmountable issues with implementing these traits
  • clarify if we could document the lack of these trait implementations in the documentation
@d-e-s-o
Copy link
Contributor Author

d-e-s-o commented Dec 31, 2021

I now found #955 touching on the subject.

@d-e-s-o
Copy link
Contributor Author

d-e-s-o commented Jan 1, 2022

I now found #955 touching on the subject.

I think that PR addresses most of my questions. Apologies for finding that only after opening the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant