shoney/writeonce
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
writeonce/docs/stories/language-runtime-database/08-shard-actor-runtime.md
shoney.arickathil a798cf6698 docs: pending iterations renumbered by dependency + priority 
- developer directive: pending iteration IDs now ARE the priority order;
  LANDED iterations keep historical numbers (code comments and commit
  history cite them — records, not a queue); 8/11 (the half-landed
  arc), 17 (parked, artifacts on a branch), 18 (next, artifacts named)
  also frozen
- mapping (recorded in 00-story): 19<-20 Float+Bytes, 20<-9c attach,
  21<-9d keypair, 22<-9e benchmarks, 23<-9f io_uring WAL, 24<-19 chat,
  25<-10 services, 26<-12 blue-green, 27<-9g query corpus,
  28<-14 skillhost, 29<-13 metaprogramming
- 11 story files renamed; every doc reference re-numbered (word-boundary
  sweep for the lettered 9x ids, phrase-level for numeric ones); the
  iterations table rewritten with Seq == priority and "(was N)" notes;
  story-scoped link check: zero broken
- merge-recovery folded in: the partial master merge had dropped the
  chat story, the fibers exploration note, the arc spec+plan, the
  framework-v2 plan, and the iteration-17 spec+plan — all restored from
  their branches and renumbered consistently

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-20 14:31:09 +02:00

2.5 KiB
Raw Blame History

Iteration 8 — shard-actor runtime

Format: fiberloom product/story-iteration-template. Part of Story — one language, one runtime, one database, one binary.

Goals

  • The runtime scales past one core the doctrine way: pinned thread-per-core shards, each owning its own heap and event loop; cross-shard communication is a message send that moves ownership — shared mutable state never exists.
  • The language grows spawn and message send; garbage collection stays per-shard, so no global pause appears at any core count.

Acceptance Criteria

  • What to achieve?
    • Given a program spawning actors across shards,
    • when an owned object is sent to another shard,
    • then the sender can no longer touch it (compile-time move), the receiver owns it, and its eventual free routes back to its allocation-home arena.
  • What to achieve?
    • Given debug builds with shard-ownership asserts,
    • when the deterministic actor corpus runs under ASan and TSan,
    • then zero races, zero leaks, and identical output across runs.
  • What to achieve?
    • Given a @gc reference,
    • when code attempts to send it cross-shard,
    • then the compiler rejects it — aliased references cannot cross heap boundaries.

Out Of Scope

  • Fibers/green threads (recorded in the blue-green vision §3; extends this scheduler later).
  • Cross-shard transactions (the database iteration's 2PC concern, later).

Info

  • The C reference (runtime/wo-rt.c, phases A–F) is the substrate: epoll loops, eventfd mail, the machinery this iteration lifts into wovm.
  • The VM's object header has carried a shard id since iteration 2 — no relayout.
  • Gated by the benchmark (2026-08-15): this is the "optimize multithreading" lever of the performance arc — thread-per-core is a throughput/scale claim, so landing it means re-running iteration 22 at the connection/concurrency scale it unlocks and recording the before/after delta. It is also where the io_uring write path (23) gets a thread to overlap durability against.

Proposed Solution

  • Execute the existing plan: docs/superpowers/plans/2026-08-01-shard-actor-vm-runtime.md (pinned-worker scheduler, shard-stamped heaps, MPSC mailbox rings + mail eventfds, send-as-move with home-routed frees, gc pacing per tick, spawn/send surface, actor corpus).