Use Rust Generator / Future for spawn / suspend / resume

[KronicDeth]

From Elixir Slack (since we lose history)

@bitwalker Today at 5:58 PM
@KronicDeth I've been considering how we might be able to unify our scheduler and execution model across platforms, including Wasm, and one thing I'd be interested in your take on: If I was to implement the platform-specific bits (i.e. the details of spawn/suspend/resume operations) as an implementation of Rust's Generator and/or Future traits, does that make things easier for us in general, especially when interoperating with the host in WebAssembly, or are there issues there. Specifically, I'm interested in your take on whether the scheduler/executor we'd end up with can be shared universally, and if it would make interaction with async code in the browser more straightforward, or if it wouldn't make much difference
9 replies

@KronicDeth 3 hours ago
I tried to Future some of the spawn stuff for the tests where they only work if you have a second process running, but I couldn't figure out how to implement the executor, but the docs were really terrible at the time I looked into it. It may be more obvious now. I haven't looked at Generator before.

@bitwalker 3 hours ago
My understanding is the executor/scheduler would need to be run with an initial future that acts as the init process. The spawn primitive then registers new futures with the executor in some predefined way, such as pushing them onto a queue, and then the executor works by polling the init future/process to determine whether the executor should terminate. As long as the init process returns Poll::Pending, you try to schedule futures. Once the init process returns Poll::Ready(_), then you'd terminate the scheduler loop and exit the executor.

@bitwalker 3 hours ago
The implementation I have in mind under the covers is to surface the suspend/resume points of the compiled code as a Generator implementation in Rust. That in turn can be converted to a Future pretty trivially, by simply having the generator itself use the Poll type as its result

@bitwalker 3 hours ago
From the executor/scheduler point of view then, processes are just futures

@bitwalker 3 hours ago
The nice thing here is that this fundamental representation can work across all platforms, including WebAssembly

@bitwalker 3 hours ago
I've been exploring this route because at the same time I implement support for WebAssembly, I wanted to get rid of the need to allocate native stacks for every process, and run processes on their schedulers' native stack. There's a handful of benefits there, but a big one is the ability to run a lot more processes in a smaller amount of memory

@bitwalker 2 hours ago
Put it all together and I think from a runtime perspective, a ton of stuff ends up looking identical on all platforms. The only platform-specific details around scheduling would live in codegen and in the implementation of the Generator trait, I think it simplifies things a ton, assuming the only difference between the WebAssembly scheduler and non-Wasm is whether or not the scheduler loop is driven externally, since we can provide two different entry points based on which style we need for a target.

@bitwalker 2 hours ago
The main things I'm uncertain about: 1.) how does this stuff look with multiple scheduler threads; 2.) can we use wakers to be smart about which processes we wake up, for example, if we suspend a process because we're making a call to a non-blocking I/O function, then we don't need to even try and resume that process until the I/O result is ready. Similar things might be true for e.g. calling a process with or without a timeout. I haven't dug into what can be done with wakers fully, but my impression is that you can do much more intelligent things in terms of scheduling with them than you otherwise would do. 3.) are there things that can't be expressed with futures/executors that would make this a bad choice for implementation.

@bitwalker 2 hours ago
You may find this useful to get a handle on the future/generator stuff, it summarizes it pretty well
cfsamson.github.io
Introduction - Futures Explained in 200 Lines of Rust
This book aims to explain Futures in Rust using an example driven approach.

[KronicDeth]

A CoroutinesToFuture converter was shown in the original RFC for generators.