Skip to main content

Module boundary

Module boundary 

Source
Expand description

The FFI surface — the only path from Core to user code.

Mirrors BindingBoundary in ~/src/graphrefly-ts/src/__experiments__/handle-core/core.ts:122–126.

§Boundary discipline (handle-protocol cleaving plane)

The Core never sees user values T. When the dispatcher needs to invoke user code, run a custom equals oracle, or release a value-handle’s refcount, it calls into BindingBoundary. The binding-side implementation resolves handles to values, runs the user code, and returns either a new handle or a no-op signal.

In a Rust core compiled to a napi-rs / pyo3 / wasm-bindgen cdylib, the impl BindingBoundary lives in the bindings crate; it owns the value registry (HashMap<HandleId, T> plus a value→handle dedup map).

Per the rust-port session doc Part 2: this trait is the only mandatory FFI crossing per fn-fire. Internal protocol bookkeeping (DIRTY propagation, batch coalescing, equals-substitution under identity, version counters, PAUSE/RESUME, INVALIDATE, first-run gate) stays Core-internal — zero FFI.

Structs§

DepBatch
Per-dep batch data passed to BindingBoundary::invoke_fn.

Enums§

CleanupTrigger
Lifecycle trigger discriminator for BindingBoundary::cleanup_for.
FnEmission
A single emission within a FnResult::Batch — one element of an actions.down(msgs) call. Processed in sequence within the same wave.
FnResult
What the binding side returns when the Core invokes a fn via BindingBoundary::invoke_fn.

Traits§

BindingBoundary
The FFI surface: every Core → user-code crossing goes through one of these three methods.