Tay.Execution.LocalFence (tay v0.7.0)

Copy Markdown View Source

VM-local exclusion between execution generations of the same STORE_ID.

Started lazily by explicit Engine startup under Tay.Supervisor; application startup itself remains storage-free. A lease is acquired before storage activation. Every callback task must be registered while still waiting and before it can receive execution authorization. The ledger contains only local process identities, bounded by the Engine's admitted execution credits.

Revocation closes registration before killing tasks. A new lease is refused until every registered task is actually dead; neither an exited supervisor nor a released native lock proves callback death. Polling the bounded PID ledger avoids delivering arbitrary callback DOWN reasons to this process or Engine.

A small persistent_term marker is installed before granting a lease and is erased only after proven retirement. This is ephemeral VM state, not durable metadata or a recovery ticket. If this process dies with an outstanding lease, a replacement deliberately refuses that STORE_ID with :local_fence_lost until a fresh VM: it cannot reconstruct a complete task ledger safely. Guardians monitor the exact fence PID and revoke their execution generation on its loss. No API clears an orphan marker or adopts an old lease.

Summary

Functions

acquire(store_id, generation, engine, guardian, runtime)

child_spec(init_arg)

Returns a specification to start this module under a supervisor.

See Supervisor.

dead(lease, relay, task)

ensure_started()

guard(arg1)

live?(lease)

live?(lease, relay, task)

register(lease, relay, task)

retired?(arg1)

revoke(lease)

start_link(options)