Function with_executor 

pub fn with_executor<R>(ex: &Rc<RefCell<Executor>>, f: impl FnOnce() -> R) -> R

Run f with ex set as the current executor.

Signal callbacks and spawn_global calls inside f will be routed to ex instead of the global thread-local executor. Restores the previous executor afterward.

Signal routing constraints

Auralis uses a single global schedule hook (installed once by the first call to init_flush_scheduler) that decides where signal notifications land by checking the current executor at the time the notification fires, not at the time Signal::set is called.

This design implies two hard requirements for multi-instance users:

1. init_flush_scheduler must be called at least once — without it, Signal::set falls back to synchronous callback execution, which breaks the deferred-notification model and can cause re-entrant borrow panics.
2. The instance executor must still be “current” when the flush runs — if with_executor has already exited, deferred callbacks from signals set inside f will be routed to the global executor (or synchronously if no global hook is installed).

For the typical single-threaded case (Wasm, game loop, CLI), both requirements are satisfied trivially: call init_flush_scheduler once at startup and never use with_executor. For SSR / multi-tenant servers, ensure that with_executor wraps the entire request lifecycle — from signal creation through the final flush.

Example

use auralis_task::Executor;

let ex = Executor::new_instance();
Executor::install_flush_scheduler(&ex, my_scheduler);
auralis_task::with_executor(&ex, || {
    // Signal notifications and task spawns here go to `ex`.
});