Batches

Batch callbacks receive a counted array of retained request handles, followed by the registered context. The array is borrowed only during the callback; copy its handles into application-owned storage to defer work without copying request bytes. Every loop deposits into one queue per batch endpoint, so batches mix requests from all loops, and partial batches flush at their configured deadline.

The batch endpoint’s polling owner can also manage the engines the batch feeds, with no thread of its own per engine. Each USearch, UStore and UForm executor runs one call at a time, and a deferred call on a caller-exclusive executor finishes on that executor’s threads, so the owner submits one deferred call per executor and replies from the status words:

ucall_server_take_batch(&take);                     // its callback copies the request handles out
search.completion = usearch_completion_deferred_k;  // every query of the batch, in one call
usearch_dense_search(&search);
read.completion = ustore_completion_deferred_k;     // every document of the batch, in one call
ustore_docs_read(&read);
while (usearch_outcome_status(search.outcome) == usearch_status_deferred_k ||
       ustore_outcome_status(read.outcome) == ustore_status_deferred_k)
    ucall_server_take_calls(&calls);                // keep serving the plain endpoints meanwhile
reply_to_each(requests, &search, &read);            // ucall_server_reply_content per request