3 ms·

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-your-function/ https://jo

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-your-function/ 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 3y ago
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.