Tasks are still running on main thread

[daBlesr]

Hello, I tried creating computationally intensive tasks on wasm web, on separate threads using:

use std::thread;
use async_task::Task;
use bevy::tasks::futures::{check_ready, now_or_never};
use web_task::{spawn};

let task: Task<Option<NavigationPath>> = spawn(async move {
  let current_thread = thread::current();
  info!(
      "Pathfinding is running on thread: name={:?}, id={:?}",
      current_thread.name(),
      current_thread.id()
  );
  let guard = obs_clone.read();
  if let Ok(obstacles) = guard.as_ref() {
      compute_path_towards(&*obstacles, pos, &target_clone, CELL_SIZE)
  } else {
      None
  }
});

but it keeps printing "main" thread. I was thinking the purpose of this library is to specifically that right? Am I doing it wrong?

[hsnoil]

I think you have to be on nightly and enable +atomics, it isn't very clear but it is mentioned:

Enabling the +atomics nightly target feature automatically enables a thread-safe runtime, which works with web-workers but which may have different performance characteristics.

The code itself only seems to have bindings for when that feature is enabled.

mod runtime {
    use cfg_if::cfg_if;

    cfg_if! {
        if #[cfg(target_feature = "atomics")] {
            mod multithread;
            pub(crate) use multithread::*;
        } else {
            mod singlethread;
            pub(crate) use singlethread::*;
         }
    }
}

[daBlesr]

Hi @hsnoil ,
thanks for your answer. I am on nightly, and I have enabled atomics. I can see that the spawn method from the multithread module is called, because I added logging locally, but still it continues to print only thread_id: ThreadId(1):

Creating spawn from multithread runtime log.target = "web_task::runtime::multithread";log.module_path = "web_task::runtime::multithread";log.file = "/Users/.../web-task/src/runtime/multithread.rs";log.line = 254;

My .cargo/config.toml looks like:

[unstable]
build-std = ['std', 'panic_abort']

[target.wasm32-unknown-unknown]
rustflags = [
    "--cfg", "web_sys_unstable_apis",
    "-C", "link-arg=--initial-memory=67108864",
    "-C", "target-feature=+atomics,+bulk-memory,+mutable-globals",
    "-Clink-arg=--export=__heap_base",
    "-C", "link-arg=--shared-memory",
    "-C", "link-arg=--import-memory",
    "-C", "link-arg=--max-memory=1073741824",
    "-C", "link-arg=--export=__wasm_init_tls",
    "-C", "link-arg=--export=__tls_size",
    "-C", "link-arg=--export=__tls_align",
    "-C", "link-arg=--export=__tls_base",
]

I see the correct response headers in the network tab:
cross-origin-embedder-policy: require-corp
cross-origin-opener-policy: same-origin

@NthTensor do you maybe also have some suggestions?

[NthTensor]

Hi! Happy people are using the lib.

This is not a thread-pool. It will not distribute your workload across a pool of web-workers. It will not create any web-workers for you. It only kinda distributes work among existing web-workers. Here's what it does:

• spawn_local polls a future to completion on the web-worker on which it is called. It does not require Future: Send. Whenever a locally-spawned future is woken, it is always sent back to the original thread to be polled. The behavior is identical to that of wasm-bindgen-futures::spawn_local, except that it returns an async_task::Task.

• spawn polls a future to completion. It does require Future: Send. When a non-locally-spawned future is woken, it runs immediately on the waking thread (which may or may not be the same thread on which it was spawned). This behavior is not supported by wasm-bindgen-futures.

If you set up a web-worker, and that web-worker calls spawn, and then the future ends up being woken by the main thread, that future will then migrate to the main thread. If you instead called spawn_local, that future would be sent back to the web-worker, and the web-worker would execute it.

The "multithreaded backend" exists to make spawn_local sound under web atomics. It does not provide multithreading, but it's sound to use with it.

The intention is for this to be used as a component to make a multi-threaded async executor for the web. I have one under development, but it's not ready to be published yet.

[daBlesr]

Ah that makes sense! If you need early playtesting of the new threadpool executor let me know 😀

[daBlesr]

Hi @NthTensor , could you use some help with the new threadpool executor?