[rogpeppe1]

One of Go's big selling points is the avoidance of the "red-blue problem" (https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...). The standard Go implementation does that by using lightweight "goroutines" that automatically suspend themselves whenever they do some operation that might block - there's no need to use an OS-level thread for each thread of control.

I wonder how the authors plan to accomplish a similar thing while remaining fully FFI-compatible.

[Leotard6963]

Note that this project is not an attempt to replace the Go runtime, but here is what we will do:

Precondition: in Go, each goroutine has its own `g` structure (like TCB, but for controlling goroutines) and its address is stored in the `g` register, which is reserved by the go compiler, active goroutines can call a function runtime.getg() to obtain the value of the `g` register.

In the official runtime, the `g` structure is a concrete type and the scheduler is implemented globally in the runtime package.

But we have made the `g` structure customizable (still requires a fixed header expected by the function prologue & epilogue and linker), so custom g implementations may contain a link to a custom scheduler, and the scheduler can decide how to handle an active goroutine.

> "goroutines" that automatically suspend themselves

The automatic suspend and resume happens by

- calling `runtime.entersyscall` from a running goroutine - and calling `runtime.exitsyscall` from an finished systemstack

all these operations can interact with the custom `g`, thus can interact with the custom scheduler.