Executors

One executor serves any number of indexes, and its kind must match the residency their handles were built for. There is a constructor per C one, each taking a config of exactly what its C structure takes:

var sockets = try usearch.Executor.forRam(.{ .memory_domains = &.{ 0, 1 }, .threads = 0 });
var shared = try usearch.Executor.onPool(fork_union_pool, .{ .memory_domains = &.{0} }); // borrows a `fu_pool_t`
var gpus = try usearch.Executor.forVram(.{ .devices = &.{ 0, 1 }, .streams = null, .scratch_limit = 0 });
var drives = try usearch.Executor.forNvme(.{ .paths = &.{.of("/mnt/nvme0")}, .threads = 0 });

Zero threads takes 7/8 of the cores, since full occupancy starves the ordered publication path; forVram takes no thread count at all, driving one stream per device from the calling thread, either its own or one of the CUDA streams you lend. drain(mood) waits until no call holds the executor, then lets the threads go .parked or stay .spinning once idle.

§ Receivers & Deferred Calls

The receiver chooses where a verb runs and how it completes, and the verb stays the same. The index runs it on the calling thread, index.on(executor) blocks on an executor, refused while another call holds it, and index.deferred(executor, &call) submits it there into a usearch.Deferred you hold:

const here = try index.search(queries, 10, &arena, .{});               // the calling thread
const there = try index.on(executor).search(queries, 10, &other, .{}); // blocking, on the executor
var call: usearch.Deferred(usearch.DenseSearch) = undefined;
try index.deferred(executor, &call).search(queries, 10, &spare, .{});  // submitted, into `call`
defer call.deinit();

DenseIndex.On and DenseIndex.DeferredOn(Call) offer every verb the index does, with the same arguments, the *Arena included, because one generic writes each verb once for both; a deferred receiver compiles only the verb its storage holds. Constructors address no index yet, so no receiver offers them; the ones the C interface lets fan out take an executor in their config, and run on the calling thread without one.

A Deferred owns what the library reports into until its call is final, the outcome and any fixed-size result, and borrows the rest, as a blocking call does. The handles it names, such as the index, the executor, the arena, a cursor or a stream, need nothing more: freeing one waits for every deferred call naming it. The plain memory it reads, such as the rows, the keys, the path, the carry and the handlers’ contexts, stays yours, and must outlive the call.

var call: usearch.Deferred(usearch.DenseGet) = undefined;
try index.deferred(executor, &call).get(key, .f32, &arena);
defer call.deinit();
if (call.status() == .deferred) {
    // other work
}
const vectors = try call.wait(); // the view a blocking `get` answers, valid until the next call given `arena`

The storage is yours to place, so submitting allocates nothing: a stack slot, a field, or an array of them for a batch of submitted calls. The library reports into the storage, so a submitted Deferred stays put until deinit; a heap slot comes from allocator.create and is destroyed after deinit. Zig has no async keyword left to lean on, so a deferred call is waited on and nothing else: status reads the outcome with acquire ordering and never blocks, and wait blocks in the library until the call is final and answers its result or error, the same one however often it is asked. deinit waits the same way, and the slot can then hold another call. A Deferred has one owner: wait and deinit never run on two threads at once, while status reads from any. message answers the static detail of the final status, empty until the call is final and on success. One call holds an executor at a time, so a second call finding it held finishes at once with Error.Contended, and nothing queues. A deferred call on a caller-exclusive pool runs on the pool’s thread 0, so polling status alone finishes it, and its progress handler and predicate run on the pool’s threads; a single thread, WebAssembly or a VRAM executor runs it at submission. Calls depending on each other are ordered by waiting on the first before submitting the second. A shape only the binding can check, like a key run longer than its rows, is refused before anything is submitted, so the submitting call itself fails and the slot holds nothing to deinit.