feat(beam): implement Async.StartChild in fable_async runtime

[dbrattli]

The gap

The Beam backend already emits fable_async:start_child/1,2 for Async.StartChild(computation[, millisecondsTimeout]) (via the catch-all in Beam/Replacements.fs + snake_case conversion), but the runtime function did not exist in src/fable-library-beam/fable_async.erl. Any F# using Async.StartChild therefore crashed at runtime with:

{undef,[{fable_async,start_child,2,[]}, ...]}

This surfaced downstream in the Scriptorium test runner (Scriptorium.Quill), whose per-test timeout helper compiles to Async.StartChild(computation, ms).

No compiler change is needed — confirmed via quicktest that the correct arities are already emitted (start_child/1 for no-timeout, start_child/2 for timeout). This PR is runtime-library only.

Implementation

Added start_child/1,2 to fable_async.erl (export, specs, body). The child runs the computation to completion in its own process via run_synchronously, then becomes a small result holder that serves the result on demand: each awaiter sends its own pid tagged with a unique ResultRef, and the holder replies to that pid. The returned inner async sends such a request and blocks on receive, with an after TimeoutMs clause that kills the child, flushes a possibly-raced reply, and raises #{message => <<"The operation has timed out."/utf8>>}.

The request/reply design (rather than the child eagerly messaging a captured self()) means the inner async matches .NET semantics in two ways that a naive version misses:

• Awaitable from any process, not only the one that called StartChild — e.g. awaiting the child inside an Async.Parallel worker (a separate BEAM process) works instead of deadlocking.
• Awaitable any number of times — the holder loops and replies to each request, instead of a single reply being consumed by the first await.

Trade-off: a child whose result is never awaited leaves an idle holder process behind (documented in a code comment).

Two Beam-specific details verified rather than assumed:

• Exception shape: on Beam, all built-in .NET exceptions compile to bare #{message => Msg} maps with no __type tag, so :? TimeoutException cannot match — asserting on .Message is the correct idiom (and matches how Quill consumes it).
• Concurrency proof: Fable Beam refs/mutables are backed by the process dictionary (process-local), so StartChild's separate processes cannot share a mutable. Concurrency is proved by timing instead.

Cancellation tokens are intentionally not propagated to the child. They are also held in the process dictionary (see fable_cancellation.erl), so a token is only meaningful within a single process and cannot be shared with the child's separate process — passing it across would crash on get(Token). This matches parallel/1; making tokens cross-process is a larger follow-up affecting both.

Tests

Six tests in tests/Beam/AsyncTests.fs: basic let! c = StartChild(...) in let! r = c → 42; concurrent execution (timing); timeout raises; completion before timeout; result awaited multiple times; and result awaited from another process (via Async.Parallel). The last two directly exercise the paths that a naive single-message implementation would hang on.

Full Beam suite: 2487 passed, 0 failed, including all six start_child tests.

🤖 Generated with Claude Code