My understanding of that PR is it relates to how the Go compiler does code generation. Rust takes a different approach and is about to ship `async / await` which is a different strategy.

Preemption is out of scope for Tokio as we are focusing on a runtime to power Rust async functions. So, for the foreseeable, Tokio will using "cooperative preemption" via `await` points.

IIRC: one of the issues with the original Rust stdlib greenthread implementation was that it's extremely difficult to preempt execution in a systems language. It's also quite difficult to add userland execution preemption without incurring significant performance penalties.

How do you preempt syscalls or FFI calls? (Go will almost certainly also have this issue with cgo modules)

I would be very surprised if preemptible Futures are something Tokio can or would implement.

What does systems mean here? There is a dirty trick with a NOP and self rewriting code that's quite cheap when not triggered. I think java does it that way.

Elaborate?

So you put in a NOP before each backward jump. To preempt you overwrite it with a jump to a handler that saves the state of the thread.

How multitasking used to work on Atari :)

But this requires code pages to be writable. Which, from a security perspective is awful.

This presumes writable code segments, which many OSes shun.

It's java. Dynamic code generated by a jit.

Which NOP do you overwrite? Do you have to do this for all backward-jump-NOPs in all loaded executable code, or do you have to determine, which loop the thread in question is executing right now?

How does that resolve syscall question?

Syscall you have to do with a signal

Preemption isn't a concept that applies to a task scheduler like Tokio. You can't just inject more states into a finite state machine at runtime.

When does that get released into Go? That sounds cool