Using async in a call-back of a blocking library

[fyl2xp1]

@SkiFire13

What do async functions do that's special then? They get compiled down to a struct that "remembers" the state and the code it was executing the last time it had to return to yield to the executor, so that the next time poll is called it can resume from that point.

And I guess that any non-async function therein makes the content opaque to the algorithm that slices the code into a state machine? If that's true, that was the missing part for understanding the problem.

[kpreid]

Yes, “the content” of the non-async function is opaque to the state machine construction. If it weren’t, then Rust would have very different properties — for example, std::thread::scope() and std::thread::LocalKey::with() couldn’t exist. There are lots of things that depend on the fact that they cannot be interrupted and saved into a state machine, but must run to completion (or unwind or abort) on the same thread.

You also wouldn’t be able to call any functions not written in Rust except with some special mechanism, since those functions are necessarily opaque.

[fyl2xp1]

Thank you all for your time and patience. I now have a better understanding of why this is impossible.

[SkiFire13]

@fyl2xp1

And I guess that any non-async function therein makes the content opaque to the algorithm that slices the code into a state machine? If that's true, that was the missing part for understanding the problem.

The algorithm that converts an async fn into a state machine never inserts additional yields. It only supports those where a .await appear, which means the async fn is evaluating another Future which might in turn yield. If that happens the async fn yields as well. So if your async function calls a sync function the algorithm will never introduce a yield because there's no .await there.

Even if this was changed and the compiler tried to see through sync functions (which is likely not gonna happen, since there's unsafe code relying on this not happening for soundness), there would still be some functions where thi would not be possible. For example there's no async equivalent of function pointers or trait objects that's would be always valid. Likewise, blocking OS syscalls need to be manually translated into the corresponding async syscalls, and that's not something the compiler can do (not to mention it requires a lot of machinery).

[2e71828]

@alice

Such an executor cannot exist in browser wasm due to how wasm works on a fundamental level

I have no experience with WASM, but my understanding is that it’s a pretty full-featured single-threaded environment as far as compute is concerned (though I/O probably has quirks).

As such, I would expect something like this¹ to be possible, though extremely inefficient— Instead of jumping up the call stack to the executor, run another copy of it within the callback and ensure that the two concurrent iterations don’t step on each other’s toes too badly.

I wouldn’t be surprised at all, though, if browser I/O events are unable to trigger a waker in this setup until control returns to the top level naturally. But that’s not necessarily the only source of wakes in the system; there’s also cross-task communication at least.

---

¹ Content warning: Extremely quick-and dirty, untested proof of concept. Probably contains deadlocks and other concurrency bugs.

[alice]

WASM fundamentally requires you to return out of WASM to yield.

[the8472]

@SkiFire13

@fyl2xp1

My naive hope was to call: surrounding_executor.lock().yield();. I'm convinced that this is not possible, but I'd like to understand the background of this.

Yeah this is not possible because a method can never return from their caller, only to their caller (not to mention it would have no way to preserve the caller's state).

Such a method could perhaps spin a custom executor's loop (obviously not the JS event loop). But you'd be paying stack frames for that, eventually leading to stack overflows if futures within the executors then in turn also call that kind of yield. So it'd be a pretty bad idea to use such a method even if it existed.

[fyl2xp1]

also it wouldn't solve my problem of giving the JavaScript runtime some time to execute other tasks as the surrounding WASM-call would still be blocking

[2e71828]

I’m still trying to wrap my head around the what the restriction is. When you say that yielding requires returning out of WASM, do you mean that the lowering of async blocks to state machines is somehow fundamentally different on the WASM platform than native?
Or that the mechanism used to deliver I/O events relies on an empty Rust stack? Or something else?

[kpreid]

Or that the mechanism used to deliver I/O events relies on an empty Rust stack?

This. There is a built-in event loop (in browsers, at least) which executes only when the JS stack and the Rust stack are empty. Actual input from the outside world (mostly) cannot arrive except by events delivered by that event loop.

[alice]

When using WASM directly in the browser, your async runtime is the JavaScript event loop. You have to yield all the way back into JS. There's no way to recursively invoke the JS event loop from within WASM. The code you shared may be able to run other Rust tasks, but the browser event loop has a bunch of other non-WASM work such as painting the screen or responding to mouse clicks or triggering pure JS timers. Those things can only run when you yield out of WASM.

[fyl2xp1]

Just completeness: I was able to work around this problem using wasm-rs-shared-channel.

The WebWorker still needs to cooperatively poll the channel, but at least the messages are getting through.