Configures and starts whichever native io backend is active
(io_uring on Linux, IOCP on Windows, kqueue/mio elsewhere, or the
tokio wrapper — see dtact_util::io::init_runtime) before the
wrapped main/entry point runs. Takes the same five knobs as
fs_init/process_init (workers, buffer_pool_size,
chunk_size, pin_cpus, ring_depth), the “power user” counterpart
to the plain dtact_util::io::init(workers) convenience function.
Sibling to dtact_io_init for the fs module: configures and starts
whichever native fs backend is active (io_uring slot pool on Linux,
IOCP slot pool on Windows, thread pool elsewhere — see
dtact_util::fs::init_fs) before the wrapped main/entry point runs.
Takes the same five knobs as dtact_io_init (workers,
buffer_pool_size, chunk_size, pin_cpus, ring_depth); ring_depth
is what actually sizes the preallocated op-slot pool for fs ops.
Sibling to fs_init for the process module: starts the
dtact-process blocking-thread pool before the wrapped main/entry
point runs. Same five knobs for call-site parity with fs_init/
dtact_io_init; only workers is actually consulted by
dtact_util::process::init_process today (see that function’s doc
for why the ring/buffer-pool knobs don’t apply to a thread-pool-
bridged backend).