class DenseIndexEvery verb is a batch over strided matrices, so a memory-mapped dataset reaches the index with no reshape and no copy, and a single vector is a one-row matrix. The breadth of the candidates rides each call rather than the handle, which lets a recall sweep run against one immutable index with no mutation between points.
A handle may be shared across threads, so no method here takes a lock. On a RAM handle, insertions and searches overlap freely: searches read only entries published behind the visibility watermark and never write to the graph, while insertions synchronize through per-node locks and publish in order. Serialization is the one exception, demanding a mutation-free window, though concurrent readers keep searching throughout.
The receiver chooses how a call runs, and the verb stays the same: the index runs every verb on the caller's thread, the On that on makes blocks on an executor, and the DeferredOn that deferred makes submits there and answers a Deferred. The filtered search and the progress handlers of the C interface stay unbound: they run on engine threads, where every candidate would pay an upcall and a throwing handler could not unwind. Filter the results of search instead, or narrow the index.
Every method here reports failure as an unchecked USearchException carrying the Status the engine named, so the per-method tags below list only the statuses that method distinctly produces. An IllegalStateException on a handle that was closed applies to all of them and is not repeated.
DenseOptions options = new DenseOptions().dimensions(2);
try (Executor pool = Executor.forRam(new int[0], null, 0, 0);
Arena arena = new Arena(pool);
DenseIndex index = DenseIndex.initRam(options, new int[0])) {
index.reserve(2);
index.insert(new Key[] {Key.of(1), Key.of(2)}, RowsView.of(new float[] {0, 1, 1, 0}, 2));
Matches matches = index.on(pool).search(RowsView.of(new float[] {0, 1}, 2), 1, arena);
System.out.println(matches.key(0, 0));
}