Ivan FB 825ae5af06
feat(ffi): RET_STALE_WARN progress callback replacing handler timeout
nim-ffi never times a handler out: a hard-cancel mid-call into the
underlying library (Waku/libp2p) can leave it half-applied. Instead, while
a request is still in flight its result callback receives a non-terminal
RET_STALE_WARN every StaleWarnInterval (5s default, Android's ANR interval;
-d:ffiStaleWarnIntervalMs to override), carrying the elapsed milliseconds as
a decimal string. The request always ends with exactly one terminal
RET_OK/RET_ERR — the dev decides what to do with a slow one, nim-ffi does
not decide for them.

This replaces the never-released per-proc {.ffi: "timeout = <ms>".} override
and the defaultRequestTimeout context field (issue #93), whose hard abort
unblocked the caller early. The stale-warn interval is an internal context
seam (staleWarnInterval), not a per-proc pragma.

Codegen: emit RET_STALE_WARN in the C/C++ headers, and guard every generated
trampoline (C, C++, Rust, and the Nim abi=c reply trampolines) to early-return
on the non-terminal code so the repeated callback can't double-free the
one-shot reply box. Typed wrappers ignore the progress signal for now; it is
delivered at the raw result-callback boundary.

Closes #126.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-11 00:59:26 +02:00
..
2026-05-19 12:43:34 +02:00