feat(sync): tell a forked child the truth about its inherited handles

[lxsaah]

Description

fork copies the address space but not the threads. A child inherits every AimDbHandle, SyncProducer and SyncConsumer the parent held — and none of the runtime thread that makes them work.

The failure was silence, not a crash: the child was told the database was open, its publish returned Ok, and the reading was discarded. That's the same failure the graph-start gate exists to prevent — set() returning Ok into a buffer nobody drains — reappearing on the other side of a fork. It's worse across a C ABI than in Rust, where a daemon that double-forks or a supervisor that forks per job is an ordinary shape rather than an exotic one.

There were two failures, not one

The original reproduction ended the child with _exit(0), so it never ran a destructor. Running one finds the second:

thread '<unnamed>' panicked at library/std/src/thread/lifecycle.rs:247:
threads should not terminate unexpectedly
   5: std::thread::lifecycle::JoinInner<T>::join
   7: aimdb_sync::handle::AimDbHandle::detach_internal

A forked child holds a JoinHandle for a thread that does not exist in this process, and joining it panics inside std. A Rust backtrace on fd 2 from inside a destructor — and this predates the recent work; the pre-#226 code joined on a helper thread too.

Detection: measured, not assumed

The obvious check is a pid comparison. It is far too expensive for where it has to sit:

	cost
try_set()	121 ns
std::process::id()	321 ns — 265% of a publish
relaxed atomic load	~0 ns

So detection is a pthread_atfork child handler, and the check on the publish path is a relaxed atomic load. Re-measured after the change, try_set() is 107 ns — the guard does not show up.

A generation counter, not a flag

A bool would poison the child permanently, including for a database the child itself attaches afterwards — a supervisor that forks per job and then does its own work would find the API dead for no reason. GENERATION is an AtomicU64 the child handler increments; anything made after the fork is fine. There's a test for exactly that.

The guard sits before the Weak upgrade, deliberately: a forked child's upgrade succeeds, because the Arc was copied with the address space. That is precisely why the buffer would otherwise accept a value nobody will read.

On installing a process-global

This crate's own rule is that no aimdb library installs a process-global. This installs one, and I think it's the exception the rule anticipates, on two conditions that are both met:

• Only the crate that owns the runtime thread can know the thread is gone. Nobody above can perform this check, so it cannot be pushed to an FFI layer — which is where it would be a genuine trespass.
• The handler is registered lazily, on the first attach, never at load time. A program that never uses the sync facade never gets one.

The handler does a single relaxed fetch_add, which is permitted in a fork handler.

fork::generation and fork::forked_since are public, which was not the original plan. A facade built on this crate has the same problem for the same reason — it must answer "is this still usable" without taking a lock the runtime thread might hold — so the two query functions are part of the surface rather than an internal detail.

no_std, and the guard that enforces it

fork is #[cfg(feature = "std")]-gated and libc is optional behind the std feature, so the --no-default-features graph pulls neither.

I widened the Makefile assertion that covers this. It grepped only for tokio; libc defaults to a std feature, so a target-specific dependency added for a std-only path un-no_stds the crate silently — the tree check would have passed while the build broke. It's now a list (SYNC_NO_STD_FORBIDDEN := tokio|libc), and I negative-tested it by reintroducing the leak:

✗ a std-only crate leaked into the no_std build
└── libc feature "default"
    └── libc feature "std"

Tests

tests/fork_safety_test.rs actually forks, which is what the acceptance criterion asked for:

• an inherited producer's set/try_set are refused, and the parent keeps publishing across the fork
• an inherited handle hands out no new producers or consumers — otherwise the guard is bypassed by making a fresh one in the child
• detach in a child is refused rather than fatal, and an inherited handle left to drop returns quietly (the parent asserts WIFEXITED, so a panic in the destructor fails the test)
• a database the child attaches after the fork works normally

Note on layering

SyncError::ForkedChild is additive rather than breaking because SyncError became #[non_exhaustive] in #228. That ordering was deliberate — reversed, this would have been a breaking change for a bug fix.

One thing left open: which layer answers first is a diagnostic question this doesn't settle. A facade's own closed-check can win over aimdb's more specific message, so a caller may read "this station is closed" rather than "created before a fork()". Closing that gap means teaching a third layer about forks to improve one string, which didn't seem worth it.

Related Issue

• Builds on feat(sync): classify SyncError by what the caller can do #228 (#[non_exhaustive]) and fix(sync): remove both busy-waits, and report why startup failed #226.

Checklist

• I have read the CONTRIBUTING.md document.
• My code follows the project's coding standards.
• I have added tests to cover my changes.
• All new and existing tests passed (make check) — relying on CI for the full matrix; cargo test -p aimdb-sync (std and no_std), both clippy legs, and the Makefile no_std guard are green locally.
• I have updated the documentation accordingly.