wasm_bindgen::JsValue within Actor?

[dimitri-lenkov]

wasm_bindgen::JsValue within Actor?

[dimitri-lenkov]

Found some thoughts from @Restioson on this exact issue:

#7

If you can give me some pointers in the current development branch on where to start tackling this problem I'm happy to poke and prod around even-if it requires duplication of code. I'm working on a code base that targets two WebRTC implementations: webrtc-rs and the WebIDL bindings to WebRTC that web_sys provides (but web_sys marks JsValue's as !Send).

I've ported some of my crude hand-rolled actors to xtra and like what I see (it worked perfectly with webrtc-rs), but when I tested the browser peers (using the web_sys bindings to WebRTC) things went all sideways haha.

Sorry for the spam. I really like this library so far ~ 🌹

---

Update: More info on !Send from another actor crate, stakker, that uses a single-threaded runtime (I'm new to Rust and finding all of this interesting lol):

https://uazu.github.io/stakker/d-whysing.html

[...] if we choose to limit ourselves to a single thread, then we can avoid those restrictions entirely and stay low-level and fast, free to use non-Send types [...]

[thomaseizinger]

Annoyingly, we currently have to enforce that the Actor is either Send or !Send because async fns in traits are not yet stable.

As a workaround, we use the async-trait proc macro which boxes the future into a trait object. At that point you unfortunately have to make a decision on what traits your type implements (i.e. type inference goes out the window) and this includes Send.

Once we have native async functions in traits, I believe we will just be able to have the Rust compiler infer whether the Actor is Send and this problem should be resolved.

[Restioson]

Having non-Send actors was endlessly annoying trying to use xtra with GTK, but unfortunately I could not get it to work :( I had some ideas about how to maybe make it work with GATs, though, so I'll keep you posted on that! Still very experimental though.

One way forward might be to fork and remove the Sync/Send bounds everywhere. This will result in every actor being !Send, which is unacceptable for general use, but for wasm it's completely ok.

[dimitri-lenkov]

@thomaseizinger thank you for the reply. I went down a path last night changing everything to #[async_trait(?Send)] and removing all Send marker traits but was met with a wall of errors that I did not understand 😿 .

I keep reading that because GAT's are now stable, that async traits are closer to being here. Once they land you bet I'll re-consider this library!

I'm going to borrow some ideas from this crate in the meantime.

Bye.