Function spawn_background 

pub fn spawn_background<F>(
    priority: CallbackPriority,
    future: F,
) -> BackgroundTaskHandle<F::Output>
where
    F: Future + Send + 'static,
    F::Output: Send + 'static,

Spawn a deferred tail on the process-global background executor.

The counterpart to Reactor::spawn, and the difference is the whole point of having both: that one needs a Reactor, which on a hosted build is the tokio runtime with its I/O and time drivers, while this one always lands on the same executor no matter who calls it and needs no capability at all. Record processing is reached from a plain std::thread — every blocking CA/PVA connection thread drives it through block_on_sync → park_on — so a tail it defers must not depend on the caller’s thread having a runtime, and must not be handed a Reactor either.

Anything awaited inside future is subject to the same rule: use sleep_background, interval_background and spawn_blocking_background rather than their ambient counterparts, and no tokio::net socket, whose reactor this executor deliberately does not have.

The band is the caller’s to name

priority picks which of the three callback queues runs the tail — C callbackRequest dispatches on CALLBACK.priority (callback.c:355-365) and record support sets that from the record it is deferring: callbackSetPriority(prec->prio, &pcb->callback) at the top of seqRecord.c:146 process(), re-read every cycle. There is deliberately no defaulted spelling of this function: a record tail that silently took one fixed band would make every record’s PRIO field select nothing, so the band is a parameter and a site with no record to name must say which band it means and why. Use CallbackPriority::from_record_prio wherever a PRIO is in hand.