/**
 * Host-side implementation of {@link createIsolate}. Owns the {@link Worker}
 * that runs the isolate, multiplexes ops onto the wire, tracks pending
 * promises by id, and enforces wall-clock timeouts via `setTimeout` +
 * `worker.terminate()`.
 *
 * Trade-off (v1, will revisit in v2): a timeout terminates the entire
 * isolate. CPU enforcement is millisecond-granular; for sub-ms or
 * tight-loop accuracy use v2 (FFI to libJSC). For now: if you need a fresh
 * isolate after timeout, pool them at the application layer.
 */
import { type Isolate, type IsolateOptions } from "./types";
/**
 * Worker-backed {@link Isolate}. The original v0 implementation; one Bun
 * Worker per Isolate, all comms through `postMessage`. Public
 * {@link createIsolate} picks this when the user passes `backend: 'worker'`
 * or when libJSC isn't reachable.
 */
export declare const createIsolateWorker: (options?: IsolateOptions) => Promise<Isolate>;
/**
 * Create an {@link Isolate}. Picks a backend based on `options.backend`
 * (default: `"auto"` — FFI if libJSC is reachable, Worker otherwise).
 *
 * The FFI backend (when reachable):
 * - Cold heap ~300 KB vs ~46 MB on the Worker backend.
 * - Closes the two T2 documented residuals (`(0, eval)('Bun')`, `new Function(...)`).
 * - Interrupt-driven timeouts that keep the isolate alive afterwards.
 * - libJavaScriptCore via `bun:ffi` — no Worker, no message-passing overhead.
 *
 * The Worker backend stays the only supported path on Windows, on Linux
 * machines without `libjavascriptcoregtk` installed, and any time the user
 * pins `backend: 'worker'` explicitly.
 */
export declare const createIsolate: (options?: IsolateOptions) => Promise<Isolate>;