Skip to content
Beskid Platform specification

Beskid

Jump to a Beskid service

Beskid

Jump to a Beskid service

Fiber scheduler and stacks - Design model

Platform spec article

Fiber scheduler and stacks - Design model

Missing owner or submitter in frontmatter for this article.

  • Run queue(s) per worker OS thread; work-stealing permitted.
  • Parked fibers live off-run-queue until wake (channel ready, cancel, join completion).
  • fiber_yield — cooperative requeue of current fiber.
  • Blocking syscall paths park fiber; blocking work runs on thread pool threads that do not execute arbitrary Beskid mutator code without attaching GC scope (Phase A: mutator attachment rules stay strict).

Implementation may use manual stack swap coroutines (see lightweight coroutines in Rust (fibers) for techniques). Requirements:

  1. Callee stack aligned to platform ABI.
  2. On switch, save callee-saved registers per ABI.
  3. GC can enumerate all fiber stacks at safepoint (stack maps required).

Phase A uses one process-wide GC arena (existing enter_runtime_scope model). OS worker threads in the pool must not execute arbitrary Beskid mutator code concurrently; they run scheduler bookkeeping or blocking syscalls without a second mutator attachment.

Only one thread at a time may hold the mutator role for GC allocation in Phase A. The scheduler transfers mutator execution between fibers on that contract. Phase B revisits parallel mutators under memory-and-gc-runtime-contract.

ProcessorCount / SetProcessorCount map to worker pool size (Go GOMAXPROCS analogue); default logical CPUs.