jonnify·bcs /bcs/elixir-core/otp-application/existence-and-the-kill

B2.1 · dive 2 — existence and the kill

Existence restored, data not.

R2 kills the portfolio store mid-flight: the supervisor restores the process, and the row written before the kill is gone. The BEAM guards data, not existence; the supervision tree guards existence; and a private ETS table dies with its owner — by design. R3 then recovers the row the only legitimate way.

Source: content/bcs2.1.md, quoting bcs_rung_2_1_check.out; the store's init is committed at lib/echo_data/bcs/property_store.ex.

The kill, step by step. The R2/R3 sequence drawn as a timeline. Select a step to read what the rung recorded at that point.
put step 1 written, gated read back step 2 the checkpoint kill step 3 table dies too restart step 4 fresh table re-put step 5 R3 recovers
readout · Select a step to read what the rung recorded at that point. The full transcript is frozen in §1 below.

The sequence, as recorded: 1 · put — a row written through the boundary; 2 · read back — the checkpoint R3 spends later; 3 · kill — the owner dies mid-flight, the private table dies with it; 4 · restart — existence restored, data not: fresh table after kill; 5 · re-put — recovered through the boundary, not the heap: re-put from a read-back row.

§1

The transcript

bcs_rung_2_1_check.out · verbatim · this dive reads R2 and R3
content/echo_data/runtimes/elixir/bcs_rung_2_1_check.out · verbatimfrozen
boot: two stores under one_for_one; native codec self-check passed at each init
R1 surface ok -- exports: six domain functions plus OTP callbacks, nothing else -- no table, no pid, no internals
R2 existence ok -- existence restored, data not: fresh table after kill -- durability is a different chapter's job
R4 radius ok -- sibling untouched (one_for_one): ord_store pid stable, row intact through prt_store's crash
R3 checkpoint ok -- recovered through the boundary, not the heap: re-put from a read-back row
R5 gate ok -- prt_store refuses an ORD name with {:error, :namespace} -- admitted kinds are per-boundary
PASS 5/5
§2

R2 — existence is the supervisor's; data is deliberately not

content/bcs2.1.md · What · property_store.ex

R2 kills the portfolio store mid-flight: the supervisor restores the process, and the row written before the kill is gone — existence restored, data not: fresh table after kill. This is the Part I correction matured into policy. The BEAM guards data, not existence; the supervision tree guards existence; and a private ETS table dies with its owner [2] — by design, because durability is a different chapter's job: the manuscript routes it to the deferred persistence adapter (Chapter 2.6, planned) and to replay from the bus (Part III, planned). A restart is a clean slate unless the design said otherwise. The fresh table is the init path re-running, committed verbatim in property_store.ex:

def init(ns) do
  {:ok, _mode} = BrandedId.self_check!()
  table = :ets.new(:bcs_props, [:ordered_set, :private])
  {:ok, %{ns: ns, table: table}}
end

The boot line carries the other inheritance: native codec self-check passed at each init — a store refuses to exist before the canon proves itself, which is clause three applied to startup. The one recorded exception to the clean slate — the heir-held table, an ETS table that survives its owner via an inheritor — trades the clean-slate guarantee for warm-cache latency, and the trade deserves its sentence too. None of the systems in this part make it.

§3

R3 — checkpoints are rows, not memories

content/bcs2.1.md · What

R3 reads a row back through the API before the kill, loses it in the crash, and recovers it the only legitimate way — recovered through the boundary, not the heap: re-put from a read-back row. State that must survive a process lives in a store: this system's, another system's, or the bus's log. Process state is working memory; anything load-bearing in it is a checkpoint that has not been written yet. R3 is the only recovery path the architecture recognizes.

Custody. A pure lookup over the chapter's custody table. Select a thing the running system holds; the readout names its guardian and the transcript line that proves it.
readout · Select a thing; the readout names its guardian and the line in §1 that proves the custody.

Static verdicts — the process → the supervision tree (R2's restart) · the table's rows → nothing across a crash, by design (R2's fresh table) · a read-back row → a checkpoint, recovered by re-put through the boundary (R3) · durability → a different chapter's job — rows, not heaps (Chapter 2.6 planned; Part III planned).

§4

References

sources · related

Sources

Related