Mutable::clone unreachable in WASM

[Christoph Herzog]

I'm getting an unreachable panic in WASM when trying to clone a Mutable.

semantic_ui_bg.wasm:0x2dc775 Uncaught (in promise) RuntimeError: unreachable
    at <std::fs::Metadata as std::sys_common::FromInner<std::sys::wasm::fs::FileAttr>>::from_inner::h0679d0c993827387 (semantic_ui_bg.wasm:0x2dc775)
    at std::sys::wasm::rwlock::RWLock::write::h49e3dbaf185ea1d0 (semantic_ui_bg.wasm:0x10d42b)
    at std::sys_common::rwlock::MovableRWLock::write::h4d92a9994597976e (semantic_ui_bg.wasm:0x2c51ca)
    at std::sync::rwlock::RwLock<T>::write::h1085ec6d35fbe88f (semantic_ui_bg.wasm:0x2ba0ab)
    at <futures_signals::signal::mutable::Mutable<A> as core::clone::Clone>::clone::h38653bcf942f42ac

[Pauan]

You will need to show me your code, most likely you are trying to clone the Mutable while simultaneously holding a lock to it, which is not allowed.

[Christoph Herzog]

Yes indeed, I was trying to clone inside signal_ref.

That's a somewhat annoying limitation. I solved it by just wrapping in Rc<Mutable<_>>, but why does cloning require a lock on the data?

And why is the panic so cryptic? Presumably because some RwLock behaviour isn't implemented on Wasm?

[Pauan]

That's a somewhat annoying limitation.

Yes it is, maybe I can fix it by using an AtomicUsize, I'll investigate it.

but why does cloning require a lock on the data?

When you clone a Mutable it has to increment a counter, so that way it knows how many copies there are. When all of the copies are dropped, it will then end the Signal.

And why is the panic so cryptic?

Exception handling isn't implemented in Wasm yet, so all error messages are just unreachable.

You can improve the error messages by using this crate, but sometimes the error messages will still be bad.

[Pauan]

I just published version 0.3.23 which makes clone lock-free, so this problem should be fixed now.

[Christoph Herzog]

Awesome, thanks!