sail-rs 0.2.10

//! Process-wide tokio runtime, initialized lazily on first use.
//!
//! NEVER initialize at import/module-load time: spawning runtime threads
//! before an application forks (common in Python preload patterns) leaves
//! the child with a dead runtime. Lazy init means a child that never
//! touched the SDK pre-fork gets a fresh runtime on first use.

use std::future::Future;
use std::sync::OnceLock;

use tokio::runtime::Runtime;

static RUNTIME: OnceLock<Runtime> = OnceLock::new();

/// Return the process-wide multi-threaded tokio runtime, building it on first
/// call. Safe to call after a fork in a child that never used the SDK pre-fork.
pub fn runtime() -> &'static Runtime {
    RUNTIME.get_or_init(|| {
        tokio::runtime::Builder::new_multi_thread()
            // The SDK is a thin RPC client; two workers cover concurrent
            // exec/wait/cancel without burning idle threads in every
            // Python process that imports sail.
            .worker_threads(2)
            .thread_name("sail-core")
            .enable_all()
            .build()
            .expect("failed to build sail-core tokio runtime")
    })
}

/// Drive a future to completion on the shared runtime, the sync facade for
/// callers outside any async context (the PyO3 bridge with the GIL released,
/// and the CLI).
///
/// `block_on` panics if called from within a tokio runtime ("Cannot start a
/// runtime from within a runtime"). Our sync entry points are never inside one,
/// so this is a debug-only guard documenting that invariant; an async Rust host
/// embedding the core should call the `async` API directly instead.
pub fn block_on<F: Future>(future: F) -> F::Output {
    debug_assert!(
        tokio::runtime::Handle::try_current().is_err(),
        "sail::block_on called from within a tokio runtime; use the async API instead"
    );
    runtime().block_on(future)
}