The rolling registry: every eval, captured (§5).
An entry is a q/task, not a value — what is retained is something that
will eventually complete, which is what makes an id useful before the work
is finished and a valid input to q/catch, q/finally and q/cancel
after it.
State lives here behind defonce and nothing else lives here at all: the
library namespaces above churn constantly during development, and ids that
evaporate on reload would break the property the registry exists for —
that an id keeps resolving.
The rolling registry: every eval, captured (§5). An entry is a `q/task`, not a value — what is retained is something that will eventually complete, which is what makes an id useful before the work is finished and a valid input to `q/catch`, `q/finally` and `q/cancel` after it. State lives here behind `defonce` and nothing else lives here at all: the library namespaces above churn constantly during development, and ids that evaporate on reload would break the property the registry exists for — that an id keeps resolving.
(capacity! n)Retain n settled, delivered entries from here on (§5). Runners and
unread results are uncounted either way. Takes effect at the next
admission — shrinking below the current pool evicts the excess then, with
the usual announcement.
Retain `n` settled, delivered entries from here on (§5). Runners and unread results are uncounted either way. Takes effect at the next admission — shrinking below the current pool evicts the excess then, with the usual announcement.
(capture! entry)Assign the next id to entry and admit it, evicting past the bound.
Within the evictable pool, eviction is least-recently-touched first — the
id gives mint order, not eviction order, so the entries being composed on
stay alive. The registry grows past the bound while work runs or waits to
be read, and one admission can evict several as it converges back.
Admission is also when the dead are reaped (§11): liveness is computed lazily, right where dead sessions' claims would otherwise shield entries forever and where the capacity formula needs the live count. No reaper thread — the machinery stays inert until asked, like everything else.
Returns {:id n :evicted [ids]} — evicted holding the admitting
session's own losses only, which the caller announces in its response;
another session's evictions are queued for their owner instead (§5), so
nobody's ids stop resolving without them hearing it.
Assign the next id to `entry` and admit it, evicting past the bound.
Within the evictable pool, eviction is least-recently-touched first — the
id gives mint order, not eviction order, so the entries being composed on
stay alive. The registry grows past the bound while work runs or waits to
be read, and one admission can evict several as it converges back.
Admission is also when the dead are reaped (§11): liveness is computed
lazily, right where dead sessions' claims would otherwise shield entries
forever and where the capacity formula needs the live count. No reaper
thread — the machinery stays inert until asked, like everything else.
Returns {:id n :evicted [ids]} — `evicted` holding the admitting
session's own losses only, which the caller announces in its response;
another session's evictions are queued for their owner instead (§5), so
nobody's ids stop resolving without them hearing it.How many settled, delivered entries are retained unless init! is told
otherwise (:capacity).
How many settled, delivered entries are retained unless `init!` is told otherwise (`:capacity`).
(entry id)The full entry map for id without refreshing or delivering — the
accessor for machinery that reports about an entry rather than reads
its result: await says how entries stand, out reads what one printed,
failure needs the baseline. Announcement-side reads (§5) must not admit
entries to the evictable pool; only res delivers.
The full entry map for `id` without refreshing or delivering — the accessor for machinery that reports *about* an entry rather than reads its result: `await` says how entries stand, `out` reads what one printed, `failure` needs the baseline. Announcement-side reads (§5) must not admit entries to the evictable pool; only `res` delivers.
(evals)One map per live entry, oldest first. The registry is shared — one JVM,
one system, global ids — so everything is listed; entries another
session minted carry :by, the owner's id prefix (nil for a
sessionless in-process caller — the wire always has a session).
Attribution, not isolation (§11): what the caller didn't make
is still labeled, never hidden. The caller's own session rides the same
rails as tee/*bank*, so this works wherever an eval navigates.
One map per live entry, oldest first. The registry is shared — one JVM, one system, global ids — so everything is listed; entries another session minted carry `:by`, the owner's id prefix (nil for a sessionless in-process caller — the wire always has a session). Attribution, not isolation (§11): what the caller didn't make is still labeled, never hidden. The caller's own session rides the same rails as `tee/*bank*`, so this works wherever an eval navigates.
(owed sid)What has settled unseen and untold for sid — settled, untouched,
unannounced, owned by that session — as [{:id n :status s} …], oldest
first. Owner-scoped (§11): the news that entry 12 finished belongs to
whoever started it, and announcing it to a stranger both leaks and
consumes the telling. A pure read; told! marks. Split, because the
marks may only land once the response carrying the news has actually
gone out (§5): a client that times out reads nothing.
What has settled unseen and untold *for `sid`* — settled, untouched,
unannounced, owned by that session — as [{:id n :status s} …], oldest
first. Owner-scoped (§11): the news that entry 12 finished belongs to
whoever started it, and announcing it to a stranger both leaks and
consumes the telling. A pure read; `told!` marks. Split, because the
marks may only land once the response carrying the news has actually
gone out (§5): a client that times out reads nothing.(owners)Session id → how many entries it owns. For the roster (§11).
Session id → how many entries it owns. For the roster (§11).
(release! sid period? self-bank)Punctuation (§11): release sid's claims on the leg of work behind it.
Every settled, undelivered entry it owns is marked delivered and told —
the caller declares it has absorbed them, and the eviction shield
lifts. With period? the punctuation is a period rather than a comma:
running entries are cancelled too, and marked — cancellation is the
outcome the caller authors (§9) — though each turns evictable only when
its cancellation actually bites, so a wedged leaf stays visible as a
protected runner rather than vanishing mid-cancel. A comma leaves
running entries alone entirely: what is still moving stays a live
concern, settled news included.
The entry evaluating the release is itself a running entry the caller
owns, so a period would cancel the mouth that spoke it (observed
2026-08-05: the report died with its own eval). It is exempt —
identified by self-bank, the eval's identity on the rails — because
punctuation ends the leg behind the caller.
Returns {:released [ids] :cancelled [ids]}, disjoint — what was absorbed versus what was stopped. The report is the audit the caller would otherwise perform by sifting its conversation for what it has read and what might still be running.
Punctuation (§11): release `sid`'s claims on the leg of work behind it.
Every settled, undelivered entry it owns is marked delivered and told —
the caller declares it has absorbed them, and the eviction shield
lifts. With `period?` the punctuation is a period rather than a comma:
running entries are cancelled too, and marked — cancellation is the
outcome the caller authors (§9) — though each turns evictable only when
its cancellation actually bites, so a wedged leaf stays visible as a
protected runner rather than vanishing mid-cancel. A comma leaves
running entries alone entirely: what is still moving stays a live
concern, settled news included.
The entry evaluating the release is itself a running entry the caller
owns, so a period would cancel the mouth that spoke it (observed
2026-08-05: the report died with its own eval). It is exempt —
identified by `self-bank`, the eval's identity on the rails — because
punctuation ends the leg *behind* the caller.
Returns {:released [ids] :cancelled [ids]}, disjoint — what was
absorbed versus what was stopped. The report is the audit the caller
would otherwise perform by sifting its conversation for what it has
read and what might still be running.(release-session! sid)A session ended — expired by silence, or said goodbye with the spec's
DELETE. Its delivery claims lapse: every entry it owns is marked
delivered and told, so the eviction shield lifts and the entries join
the LRU pool — still res-able by anyone until capacity pressure
claims them. Death degrades; it does not delete (§11). Running entries
are marked too: not evictable until they settle, but the moment they
do, their reader being gone, they owe nobody anything.
A session ended — expired by silence, or said goodbye with the spec's DELETE. Its delivery claims lapse: every entry it owns is marked delivered and told, so the eviction shield lifts and the entries join the LRU pool — still `res`-able by anyone until capacity pressure claims them. Death degrades; it does not delete (§11). Running entries are marked too: not evictable until they settle, but the moment they do, their reader being gone, they owe nobody anything.
(res id)The entry for id: the eval's task. Deref for the value — safe to repeat,
a settled task holds its result permanently. Compose rather than wait:
(q/get-ex (res 12)) is the exception as a value — cancellation
included, where catch propagates it — and (q/cancel (res 12))
cancels. Access refreshes the entry: what is in use is the last to be
evicted. Throws on an id that does not resolve.
The entry for `id`: the eval's task. Deref for the value — safe to repeat, a settled task holds its result permanently. Compose rather than wait: `(q/get-ex (res 12))` is the exception as a value — cancellation included, where `catch` propagates it — and `(q/cancel (res 12))` cancels. Access refreshes the entry: what is in use is the last to be evicted. Throws on an id that does not resolve.
(status task)Where task stands: :running, :cancelled, :failed or :done.
Never blocks and never throws — q/await with a zero bound is the
settled check, and settlement is final, so the checks after it cannot be
outraced by the task failing mid-read. Cancelled before exceptional: a
cancelled task holds a CancellationException, and reporting one as
failed would report the wrong thing — cancellation is a control signal,
not an error (§9).
Where `task` stands: `:running`, `:cancelled`, `:failed` or `:done`. Never blocks and never throws — `q/await` with a zero bound is the settled check, and settlement is final, so the checks after it cannot be outraced by the task failing mid-read. Cancelled before exceptional: a cancelled task holds a CancellationException, and reporting one as failed would report the wrong thing — cancellation is a control signal, not an error (§9).
(task id)The task for id, without refreshing or delivering — see entry.
The task for `id`, without refreshing or delivering — see `entry`.
(told! ids)Mark ids announced — told once. Announcing is not delivery: the footer
says that an eval finished, not what it produced, so the entries stay
protected from eviction until a res actually reads them (§5).
Mark `ids` announced — told once. Announcing is not delivery: the footer says *that* an eval finished, not what it produced, so the entries stay protected from eviction until a `res` actually reads them (§5).
(touch! id)Mark id delivered — its outcome has reached a caller — and refresh it.
The transport calls this when a response reports the outcome; res calls
it on every access. An entry never touched is never evicted (§5).
Mark `id` delivered — its outcome has reached a caller — and refresh it. The transport calls this when a response reports the outcome; `res` calls it on every access. An entry never touched is never evicted (§5).
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |