This is because it relies on a scheduler outside of our domain (JavaScript)

Solution: allow to run a callback after the queue is exhausted

This changes single_threaded::run_cooperatively type signature a bit, adding an extra parameter.

The testing is still not perfect as we can't really ensure the callback was called, but if it was, then we can run the assertions.

This can be alternatively done by something like join_all for all futures representing tasks scheduled and spawning another task to do something after they've been joined, but it seems at the time that adding this callback has lower impact / easier ergonomics (but, of course, it's less "pure" if you may)

This is confusing (why would it be an Option?).

Solution: make it return the value

It looks like we can pretty much guarantee that the receiver stays non-dropped during the entire lifetime of block_on, hence sending a oneshot message from the spawned task will be successful and the receiver will be able to retrieve the data.

Under certain circumstances, browser or JavaScript related dependencies might be pulled in for targets like wasm32-wasi. This is undesirable.

Solution: separate wasm32-unknown-unknown dependencies

Solution: include CI tests for wasi target using wasmtime and wasmer

This change also makes sure cooperative won't be enabled for wasm32-wasi since it's currently specific JavaScript environment.

It can be done but requires manual instrumentation of it with a oneshot channel or something like that.

Solution: instrument all spawned tasks with this approach and allow joining to retrieve the result

This follows the API pattern in Tokio.

This requires either cooperation with the task itself or introspecting into task list, neither of which is succinct.

Solution: make Task implement Future to allow for joining

This token thing is really internal to the design of the executor yet it leaks into some semi-public APIs. It's confusing and unnecessary.

Solution: unify everything under the term of "task" and carry the type information in Task (if debug is enabled)

Particularly, yield_animation_frame and yield_until_idle might panic when checking for the ouput, trying to unwrap a value.

Solution: de-reference output before checking it for is_some() instead of taking as_ref as that means is_some() is checked on the pointer, not the target value.

It only allows to run tasks cooperatively under setTimeout and will always execute just one iteration before yielding back to the browser, therefore taking control of the behaviour. It would have been nice to have more control over yielding in the tasks themselves.

Solution: introduce manual yielding primitives single_threaded::yield_timeout, single_threaded::yield_async and single_threaded::yield_animation_frame

These functions return futures that first yield to the environment using setTimemout or requestAnimationFrame, respectively. These futures will be ready and will produce the output of the enclosed future (if there's one) once yielded and those future produced the output.

This allows tasks to control the yielding to a (hopefully) sufficient degree.

Also, this change saves until argument to run at the yield/resume threshold, so the executor will stop if until is specified to be a certain task when that task is done.

This PR obsoletes #14

Now, I am not 100% sure it is safe -- simply because I've only spent a few days on this library.

I've published it as unsafe at first because I do remember transmuting some futures into a static lifetime somewhere higher up in the code :)

But the reality is that spawn itself requires task's future to be of static lifetime. Which is how it is in wasm-bindgen-future. Which is how it should be.

The only time we're actually extending lifetime is when we block on a future to run it to completion under the assumption that since it will run to completion at that point, it is safe to do so (whether I am actually correct is something to be seen)

Solution: remove the unsafe marker

It doesn't 100% guarantee I am right, but this is the best I can come up with right now.

Running Rust thread in the browser using single_threaded::run locks the thread for good. One can call JavaScript functions from it but can't really expect asynchronous APIs to work.

This is not always the most desirable trade-off.

Solution: introduce run_cooperatively function

It works the same way as run, however, after just one iteration of processing its task queue, it relinquishes control to JavaScript and schedules its own execution (provided it has not reached requested outcome).

> wasm-pack build
[INFO]: 🎯  Checking for the Wasm target...
[INFO]: 🌀  Compiling to Wasm...
   Compiling async-executor-demo v0.1.0 (/Users/kyle/github/rust/async-executor/example)
error[E0308]: mismatched types
  --> example/src/lib.rs:71:24
   |
71 |     executor::run(Some(task1));
   |                        ^^^^^ expected struct `Task`, found struct `TaskHandle`
   |
   = note: expected struct `Task`
              found struct `TaskHandle<()>`

For more information about this error, try `rustc --explain E0308`.
error: could not compile `async-executor-demo` due to previous error
Error: Compiling your crate to WebAssembly failed
Caused by: failed to execute `cargo build`: exited with exit status: 101
  full command: "cargo" "build" "--lib" "--release" "--target" "wasm32-unknown-unknown"

> cargo --version
cargo 1.60.0 (d1fd9fe2c 2022-03-01)
> rustc --version
rustc 1.60.0 (7737e0b5c 2022-04-04)

Sorry, but I am confused. I am using wasm_rs_async_executor::single_threaded::block_on, and I believe it is causing this runtime error: there is no reactor running, must be called from the context of a Tokio 1.x runtime.

Is wasm_rs_async_executor designed to be used without tokio, or does it require tokio?