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 57b4b56eae docs: stories foldered by state — done/ and refine/ 
- done/ (11): 1, 2, 3, 4, 6, 7, 7b, 9, 9b, 15, 16 — landed iterations
  (9/9b remainders live in the post-12 drain list, not in the files)
- refine/ (8): 9c, 9d, 9e, 9f, 9g, 11, 13, 14 — everything marked
  "no spec yet / brainstorm before planning"
- root keeps: 00-story (index), 05 (partial, plan 8 open), 8/10/12
  (specs or plans exist), 17 (parked, spec+plan approved), 18 (next)
- every cross-reference re-pathed and VERIFIED resolving: board, specs,
  plans, employee-list README, story table, intra-story links (moved
  files' relative links deepened one level; done/7b's 9e pointer now
  crosses to refine/)
- pre-existing dead link noted, not touched: refine/11-fibers.md points
  at docs/plan/exploration/fibers/00-fibers.md which does not exist
  (predates the move)

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-20 04:33:24 +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 9e at the connection/concurrency scale it unlocks and recording the before/after delta. It is also where the io_uring write path (9f) 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).