Switch to using Arc inside JsFuture

[hydroper]

Motivation

I've a timing API which uses either the Tokio runtime or the browser. The problem is that Tokio timing functions return a future with a Send bound and JsFuture doesn't implement Send due to containing an Rc.

I'm not planning to expose a thread API in my framework; rather, I'll have a gaming API that uses concurrent systems only on some platforms, excluding the browser (in default platforms, the gaming API would create threads internally).

Proposed Solution

Put an Arc inside instead with a RwLock inside instead of Rc<RefCell>.

Alternatives

N/A

Additional Context

N/A

[Liamolucko]

Replacing the Rc<RefCell<Inner>> with an Arc<RwLock<Inner>> still wouldn't make JsFuture Send, since Inner isn't Send either.

The main reason for that is because JsFuture resolves to a Result<JsValue, JsValue>, and JsValue is inherently !Send (each Worker used in Wasm multithreading is pretty much a completely separate JS engine, so JS values can't be shared between threads).

That basically rules out using a standard JsFuture, unfortunately. If you want to write something by hand, you can get rid of that (since sleep doesn't need to return anything), and in fact you don't need to use promises at all - you can directly build a future on top of setTimeout, kind of like gloo-timers does.

Even if you do that though, there's still another roadblock to making the future Send, which is cancellation. Ideally you'd call clearTimeout to cancel the timeout when the future gets dropped, but you can only do that if you're still on the same thread where the timeout was created.

So, the only way to do that would be to just... not clear timeouts on drop. You'd also then have to use Closure::once_into_js to make sure the closure's still valid when the timeout eventually fires, which also sidesteps the issue of Closures not being Send either.

An alternative, since you said that you aren't intending to support multithreading, would just be to unsafely declare your future Send despite it containing a !Send JsFuture, and then panic / fail to compile if multithreading is enabled (which you can detect using cfg(target_feature = "atomics")).

[hydroper]

@Liamolucko After all, I think having !Send + !Sync futures isn't a problem. My timing API is guaranteed to return !Send + !Sync futures in all platforms (uses tokio for all platforms except the browser) and I'll have this:

• The gaming API, running ECS systems, will receive Send + Sync types (for example, the graphics API won't store futures in the nodes, so no problem; and that doesn't make sense anyway), cloning node references from the graphics API freely.
  • All systems are synchronous, I suppose, which makes sense. If they need asynchronous code, they'll call exec_future(async {});, which runs a future in the background
• Workers that use a scripting language (like either Rune or Rhai)

(I didn't begin working in these things yet, not even the graphics API.)

That basically rules out using a standard JsFuture, unfortunately. If you want to write something by hand, you can get rid of that (since sleep doesn't need to return anything), and in fact you don't need to use promises at all - you can directly build a future on top of setTimeout, kind of like gloo-timers does.

Interesting, it looks like gloo-timers uses oneshot::Receiver

Even if you do that though, there's still another roadblock to making the future Send, which is cancellation. Ideally you'd call clearTimeout to cancel the timeout when the future gets dropped, but you can only do that if you're still on the same thread where the timeout was created.

I honestly didn't find that cancelling timeouts on Drop is very clear on intent. I've added cancellable versions:

• background_timeout(callback, duration) returns BackgroundTimeout with a stop() method
• background_(default|animation)_interval(callback, period) returns a similiar BackgroundInterval

Here's what I've for background_animation_interval:

pub fn background_animation_interval(callback: Box<(dyn Fn(Duration) + Send + Sync + 'static)>, period: Duration) -> BackgroundInterval {
    let mut stopped = Arc::new(RwLock::new(false));
    exec_future({
        let stopped = Arc::clone(&mut stopped);
        async move {
            let mut interval = animation_interval(period);
            interval.tick().await;
            loop {
                let delta = interval.tick().await;
                if *stopped.read().unwrap() {
                    break;
                }
                callback(delta);
            }
        }
    });
    BackgroundInterval {
        stopped,
    }
}