Executors

An executor owns the host threads or device streams; an index owns the entries. One executor serves several indexes, and its residency must match theirs. There is a constructor per C one, each taking every argument its own hardware has as an option, where zero and an empty list derive:

ExecutorForRam["MemoryDomains"->{0, 1}, "Threads"->0]
ExecutorOnPool[poolAddress, "MemoryDomains"->{}]                     (* borrows a fu_pool_t *)
ExecutorForVram["Devices"->{0}, "Streams"->{}, "ScratchLimit"->0]
ExecutorForNvme["Paths"->{"/dev/nvme0n1"}, "Threads"->0]
ExecutorDrain[executor, "parked"]                                    (* or "spinning" *)

ExecutorDrain picks whether the workers sleep or spin once idle, parked when the mood is left out. "Streams" lists borrowed CUDA stream addresses, one per device, and an empty list makes the executor create its own.

§ Receivers

The receiver chooses where a verb runs, and the verb stays the same. A DenseIndex runs it on the kernel’s own thread, and DenseIndexOn[index, executor] fans it out over an executor’s workers:

matches = DenseSearch[index, queries, 10, arena];                            (* the kernel's thread *)
matches = DenseSearch[DenseIndexOn[index, executor], queries, 10, arena];    (* the executor's workers *)

Either way the call blocks and returns once its outcome is final, so a notebook never polls, waits or orders calls. The C interface’s deferred calls are left out of this binding. Constructors address no index yet, so they take no receiver; the ones the C interface lets fan out take an "Executor" option instead.