Crate dtact_util 

Async I/O, filesystem, process, signal, stream, and timer primitives for the dtact coroutine runtime.

Two backend families are available behind Cargo features:

• native — hand-rolled, lock-free backends (io_uring on Linux, kqueue/IOCP elsewhere, thread-pool bridges where a true async syscall path doesn’t exist) built directly on dtact’s coroutine scheduler, no tokio dependency.
• tokio (default) — thin wrappers over tokio’s equivalents, for embedding in a tokio-based application instead of dtact itself.

Each of the six primitive modules (io, fs, process, signal, stream, timer) exposes the same public surface regardless of which backend feature is enabled, so callers can switch backends without rewriting call sites.

Modules

fs

Async filesystem primitives.

io

I/O primitives: TCP listener/stream, UDP socket, native and tokio-backed.

lockfree

Shared lock-free building blocks used by every module in this crate’s native backends.

process

Async child-process primitives.

signal

Async signal delivery.

stream

In-process duplex byte-stream pipes.

sync

In-process async synchronization primitives — the tokio::sync counterpart of this crate’s I/O modules.

timer

Async timer primitives: sleep, interval, timeout.

Attribute Macros

fs_init

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.

init

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.

process_init

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).