Interesting! But where to start? #36

drmingdrmer · 2022-04-21T07:08:58Z

It looks like generator-rs implements concurrent programming in another way than the future.
Am I right?

I'd like to learn more about how it works. But I am not an expert in this area:(.
Where can I find some doc/reference about the way in which the generator is implemented?

Thanks a lot! :DDD

The text was updated successfully, but these errors were encountered:

loongs-zhang · 2022-10-21T08:20:28Z

It looks like generator-rs implements concurrent programming in another way than the future. Am I right?

I'd like to learn more about how it works. But I am not an expert in this area:(. Where can I find some doc/reference about the way in which the generator is implemented?

Thanks a lot! :DDD

this is a low-level lab, dirctly use https://github.com/Xudong-Huang/may

xiaoniaoyouhuajiang · 2025-04-15T11:15:43Z

@drmingdrmer generator-rs implements concurrency using a different approach than Rust's standard async/await (Futures) model. It provides the low-level building blocks for stackful coroutines, often also referred to as "green threads".
Here's a breakdown of how it works and where to look in the codebase:

Core Idea: Stackful Coroutines vs. Stackless Coroutines (Futures)

async/await (Stackless): When an async function awaits, its current state (local variables needed later) is saved into a state machine (a Future). The function's stack is unwound. When resumed, the state is restored, and execution continues. It doesn't require a separate stack for each task.
generator-rs (Stackful): Each coroutine created using generator-rs gets its own separate execution stack. When a coroutine yields (pauses), its entire execution context (CPU registers and its stack pointer) is saved. When it resumes, this context is restored, and execution continues on its dedicated stack, just like a regular thread context switch but managed in user space.

Key Implementation Details in generator-rs:

Context Switching (reg_context.rs, detail/): This is the heart of the mechanism.
- RegContext holds the saved state of a suspended coroutine, primarily its registers (Registers struct).
- The detail/ directory contains platform-specific code. Crucially, detail/asm/ has assembly routines (swap_registers) for each supported architecture/platform. These routines perform the actual saving of the current coroutine's callee-saved registers and stack pointer into its RegContext, and then loading the registers and stack pointer from the RegContext of the coroutine being resumed.
- initialize_call_frame sets up the initial register state for a new coroutine so that it starts executing the provided function when first switched to.
Stack Management (stack/):
- The Stack struct manages the allocation and deallocation of the separate memory regions used as stacks for each coroutine.
- Platform-specific files (unix.rs, windows.rs) handle the actual memory allocation (like mmap or VirtualAlloc).
- Guard pages are often used (see overflow_*.rs) to help detect stack overflows.
Yielding (yield_.rs, scope.rs): These modules (along with parts of gen_impl.rs) provide the higher-level API for a coroutine to pause itself (yield) and potentially pass data back to its caller. These yield operations ultimately trigger the context switch via RegContext::swap.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Interesting! But where to start? #36

Interesting! But where to start? #36

Uh oh!

Uh oh!

Interesting! But where to start? #36

Interesting! But where to start? #36

Comments

Uh oh!

Uh oh!

Uh oh!