P3 async lowering: transform stream<T>/future<T>/async exports to RFC #46 host intrinsics

[avrabe]

Context

WASM P3 (WASI 0.3) introduces stream<T>, future<T>, and async component exports. Meld currently handles P2 components (synchronous only). RFC #46 establishes that Meld lowers component model constructs to core modules at build time, with the runtime providing host intrinsics.

For P3, Meld's job expands: lower async constructs to RFC #46 host intrinsic calls.

Problem

P3 async constructs can't be resolved at build time because they represent temporal relationships (data flowing over time). But they CAN be lowered to host intrinsic calls at build time, just like Meld already lowers canonical ABI lift/lower.

Proposal

1. Lower stream<T> to host intrinsics

P3 component-level:

export process: func(input: stream<command>) -> stream<telemetry>;

Meld-lowered core module:

;; Import stream operations from host
(import "pulseengine:async" "stream_new" (func $stream_new (result i64)))
(import "pulseengine:async" "stream_read" (func $stream_read (param i32 i32 i32 i32) (result i32)))
(import "pulseengine:async" "stream_write" (func $stream_write (param i32 i32 i32 i32) (result i32)))
(import "pulseengine:async" "stream_close_readable" (func $close_r (param i32)))
(import "pulseengine:async" "stream_close_writable" (func $close_w (param i32)))

2. Lower async exports to callback trampolines

P3 callback lifting mode (preferred for embedded):

• Component exports a callback function
• Host calls callback when async event occurs
• No persistent stack per in-flight async call
• Perfect for cFS-style "process one message at a time" pattern

Meld generates:

;; Callback trampoline: called by host when stream has data
(func $__callback_trampoline (param $event_type i32) (param $payload i32)
    ;; Dispatch based on event type
    ;; EVENT_STREAM_READ=2 → call component's message handler
    ;; EVENT_SUBTASK=1 → call component's subtask completion handler
)
(export "__callback" (func $__callback_trampoline))

3. Generate stream adapter code for cross-component streams

When two fused components share a stream<T>:

• Same memory (single-memory mode): Direct ring buffer access, zero-copy
• Different memories (multi-memory mode): Adapter copies elements across memory boundaries via stream_read → stream_write chain

4. Static validation at build time

Meld can verify at build time:

• Stream type compatibility (source stream<T> matches sink stream<T>)
• Backpressure configuration (bounded channels have capacity set)
• No circular stream dependencies (would deadlock)
• Resource lifetime correctness across async boundaries

P3 Callback vs Stackful

Meld needs to support both P3 async lifting modes:

Callback mode (preferred for embedded/Gale):

• Component provides (callback ...) canonical option
• Meld generates callback dispatch trampoline
• One shared stack per component
• Lower memory overhead

Stackful mode (for languages with native async/await):

• Component uses task.wait/task.yield to suspend
• Meld generates calls to thread_new/thread_switch_to intrinsics
• Each in-flight async call needs its own stack
• Higher memory overhead but more natural for Rust async, Go, Java

Connects to

• kiln#226 (cFS Software Bus as host routing — streams ARE the SB)
• kiln P3 runtime issue (host intrinsic implementations)
• Gale typed ring buffer extension

Priority

High — P3 support is the next major feature for the Component Model ecosystem.

References

• RFC fix: correct callee_defines_resource for sentinel type entries #46 toolchain architecture: Kiln docs/architecture/rfc46-toolchain-architecture.md
• P3 async: https://github.com/WebAssembly/component-model
• WASI 0.3: https://wasi.dev/roadmap

[avrabe]

Audit — what's shipped, what's outstanding (2026-05-12)

Re-reading the original proposal section by section against current main (commit 59e76d8, v0.7.0).

✅ Shipped

#	Original deliverable	Where it landed	Evidence
1	Lower stream<T> / future<T> to host intrinsics under "pulseengine:async" (14 verbs total — 7 each for stream + future)	#124 (foundation), #129 (full lowering pass)	meld-core/src/p3_async.rs (~1019 LOC), HostIntrinsic::{Stream,Future}* enum, lower_p3_async_intrinsics, LoweringPlan
2	Async-export callback trampoline (event-type dispatch — STREAM_READ, STREAM_WRITE, SUBTASK, etc.)	#128	meld-core/src/adapter/fact.rs::generate_async_callback_adapter; event::* and callback::* constants pinned by meld-core/tests/p3_async_lowering.rs
3	Closed AbiError enum + result decoders + partial-write / backpressure semantics	#127 (closes #121)	meld-core/src/p3_async.rs — AbiError, StreamWriteResult, StreamReadResult, FutureReadResult; safety/adr/ADR-2-p3-async-error-conventions.md; 22 encoding-pin tests in meld-core/tests/p3_async_abi.rs
4	Static detection of which P3 constructs a component uses	#124	Fuser::p3_async_summary() returning Vec<(Option<String>, P3AsyncFeatures)>
5	callback::POLL dispatch (LS-A-9 Mythos finding)	v0.6 release commit	branch on code == WAIT || code == POLL in adapter/fact.rs

ADRs: ADR-1 (lowering), ADR-2 (error conventions). Approved LS entries: LS-A-7/8/9, LS-CP-3.

❌ Outstanding (still in scope of this umbrella)

#	Original deliverable	What's missing
A	Cross-component stream adapters — when two fused components share a stream<T> end-to-end. Same-memory mode = direct ring buffer (zero-copy); different-memory = stream_read → stream_write chain adapter	Current pipeline lowers each component's stream intrinsics to host imports but does not fuse two components' stream endpoints together. Nothing in merger.rs or adapter/fact.rs emits a stream-bridging adapter.
B	Static validation at build time — (i) stream type compatibility between source and sink, (ii) bounded-channel capacity present, (iii) circular stream dependencies, (iv) resource lifetime across async boundaries	None of (i)–(iv) implemented. Note: general circular-dep detection exists in resolver.rs but is module-level, not stream-level.
C	Stackful lifting mode — task.wait / task.yield with thread_new / thread_switch_to intrinsics, separate stack per in-flight async call	Only callback mode is emitted. task.wait is parsed (parser.rs:208, fact.rs:3806) but no stackful trampoline is generated.

Recommendation

Don't close #94. The umbrella has real remaining substance and the issue body is the cleanest statement of what's still outstanding. Three options for the residual:

1. Keep P3 async lowering: transform stream<T>/future<T>/async exports to RFC #46 host intrinsics #94 open as the umbrella, file three sub-issues — A (cross-component stream adapters), B (static validation), C (stackful mode) — and link them from this issue.
2. Close P3 async lowering: transform stream<T>/future<T>/async exports to RFC #46 host intrinsics #94, open a new umbrella "P3 async lowering — phase 2" that lists the same three.
3. Close P3 async lowering: transform stream<T>/future<T>/async exports to RFC #46 host intrinsics #94, open three separate non-umbrella issues since the three are independent.

Option 1 mirrors the #130 DWARF-phases pattern in this repo and is probably cleanest. Recommend that unless you'd rather a fresh umbrella for v0.8.

Order of attack if work resumes: C (stackful) is the smallest-touch — adds a second trampoline shape alongside the existing callback one, parallel to #128. A (cross-component stream) is the highest-leverage — actually fuses stream-passing components into one module the way meld fuses everything else. B (validation) is the cheapest in LOC but needs A landed first to have something concrete to validate against.

No PRs being opened from this audit — just disposition.