CABI: redefine reentrance rules in terms of component instance flag

Author: lukewagner

design/mvp/Concurrency.md

@@ -3,9 +3,7 @@
 This document contains a high-level summary of the native concurrency support
 added as part of [WASI Preview 3], providing background for understanding the
 definitions in the [WIT], [AST explainer], [binary format] and [Canonical ABI
-explainer] documents that are gated by the 🔀 (async) and 🧵 (threading)
-emojis. For an even higher-level introduction, see [these][wasmio-2024]
-[presentations][wasmio-2025].
+explainer] documents that are gated by the 🔀 (async) and 🧵 (threading) emojis.
 
 * [Goals](#goals)
 * [Summary](#summary)
@@ -56,8 +54,8 @@ concurrency-specific goals and use cases:
 * Allow polyfilling in browsers via JavaScript Promise Integration ([JSPI])
 * Avoid partitioning interfaces and components into separate ecosystems based
   on degree of concurrency; don't give components a "[color]".
-* Maintain meaningful cross-language call stacks (for the benefit of debugging,
-  logging and tracing).
+* Allow runtimes to maintain meaningful cross-language call stacks (for the
+  benefit of debugging, logging, tracing and profiling).
 * Consider backpressure and cancellation as part of the design.
 * Allow non-reentrant synchronous and event-loop-driven core wasm code that
   assumes a single global linear memory stack to not have to worry about
@@ -120,13 +118,14 @@ language's style of concurrency, most `world`s (including `wasi:cli/command`,
 functions so that the contained Core WebAssembly code is free to block.
 Implementing a non-`async` function will primarily only arise when a component
 is *virtualizing* the non-`async` *imports* of a `world` (e.g., the getters and
-setters of `wasi:http/types.headers`). In this virtualization scenario (once
-functions are allowed to be [recursive](#TODO)), the Canonical ABI and/or Core
-WebAssembly [stack-switching] proposal will allow a parent component to
-implement a child's non-`async` imports in terms of the parent's `async`
-imports in the same manner as [JSPI]. Thus, overall, `async` in WIT and the
-Component Model does not behave like a "color" in the sense described by the
-popular [What Color Is Your Function?] essay.
+setters of `wasi:http/types.headers`). In this more exotic virtualization
+scenario, a [future extension](#TODO) could allow a parent component that
+imports `async` functions to implement its child's non-`async` imports in the
+same manner as [JSPI] in the browser.
+
+Thus, overall, `async` in WIT and the Component Model does not behave like a
+"color" in the sense described by the popular [What Color Is Your Function?]
+essay.
 
 Each time a component export is called, the wasm runtime logically spawns a new
 [green thread]  (as opposed to a [kernel thread]) to execute the export call
@@ -190,18 +189,23 @@ immediately block.
 This backpressure mechanism provides the basis for how the sync and async ABIs
 interoperate:
 1. If a component calls an import using the async ABI, and the import is
-   implemented by a component using the sync ABI, and the callee blocks,
-   execution is immediately transferred back to the caller (as required by the
-   async ABI) and the callee's component instance is marked "suspended".
-2. If another async call attempts to start in a "suspended" component instance,
-   the Component Model automatically makes the call block, the same way as when
-   backpressure is active.
+   implemented by a component using the sync ABI, the callee first acquires
+   an "exclusive" on the component instance, and then starts executing. If
+   the callee blocks, execution is immediately transferred back to the caller
+   (as required by the async ABI).
+2. If another async call attempts to start in this same component instance, the
+   callee immediately block when acquiring the "exclusive" lock, waiting for the
+   previous call to return and release the lock.
 
 Note that because functions without `async` in their type are not allowed to
-block, non-`async` functions do not check for backpressure or suspension; they
-always run synchronously. Components exporting a mix of `async` and non-`async`
+block, non-`async` functions do not attempt to acquire the "exclusive" lock;
+they just barge in. Components exporting a mix of `async` and non-`async`
 functions (which again mostly only arises in the more advanced virtualization
-scenarios) must thus take care to handle non-`async` reentrance gracefully.
+scenarios) must therefore take care to handle the "barges in" case gracefully.
+Because this nested non-`async` call will complete synchronously without
+blocking, this behavior does not break [component invariant] #3 since a single
+global shadow stack can still be (re)used in a LIFO manner to implement the
+nested synchronous call in much the same manner as a traditional signal handler.
 
 Lastly, WIT is extended with two new type constructors—`future<T>` and
 `stream<T>`—to allow new WIT interfaces to explicitly represent concurrency in
@@ -314,20 +318,14 @@ of the new subtask created for the import call. Thus, one reason for
 associating every thread with a "containing task" is to ensure that there is
 always a well-defined async call stack.
 
-A semantically-observable use of the async call stack is to distinguish between
-hazardous **recursive reentrance**, in which a component instance is reentered
-when one of its tasks is already on the callstack, from business-as-usual
-**sibling reentrance**, in which a component instance is reentered for the
-first time on a particular async call stack. Recursive reentrance currently
-always traps, but will be allowed (and indicated to core wasm) in an opt-in
-manner in the [future](#TODO).
-
-The async call stack is also useful for non-semantic purposes such as providing
-backtraces when debugging, profiling and tracing. While particular languages
-can and do maintain their own async call stacks in core wasm state, without the
-Component Model's async call stack, linkage *between* different languages would
-be lost at component boundaries, leading to a loss of overall context in
-multi-component applications.
+The async call stack is not currently semantically observable to the running
+components other than possibly, nondeterministically, as part of the callstack
+stored in 📝 `error-context`. But this async call stack is also useful for
+other purposes such as providing backtraces when debugging, profiling and
+tracing. While particular languages can and do maintain their own async call
+stacks in core wasm state, without the Component Model's async call stack,
+linkage *between* different languages would be lost at component boundaries,
+leading to a loss of overall context in multi-component applications.
 
 There is an important gap between the Component Model's minimal form of
 Structured Concurrency and the Structured Concurrency support that appears in
@@ -489,7 +487,11 @@ all of which are described above or below in more detail:
   [`subtask.cancel`](#cancellation) built-in
 
 At each of these points, the [current thread](#current-thread-and-task) will be
-suspended and execution will transfer to a caller's thread, if there is one.
+suspended and execution will transfer to a caller's thread, if there is one, or
+if not, the runtime, which may invoke new component exports or
+nondeterministically select a cooperative thread that is ready to run and resume
+it. Thus, each of these represents **cooperative yield points**.
+
 Additionally, each of these potentially-blocking operations will trap if the
 [current task's function type](#current-thread-and-task) does not declare the
 `async` effect, since only `async`-typed functions are allowed to block. As an
@@ -1379,9 +1381,9 @@ comes after:
   type to block during instantiation
 * add an `async` effect on `resource` type definitions allowing a resource
   type to block during its destructor
-* `recursive` function type attribute: allow a function to opt in to
-  recursive [reentrance], extending the ABI to link the inner and
-  outer activations
+* allow a parent component to perform [JSPI]-like suspension of the sync calls
+  of its child components, thereby allowing the parent to implement the child's
+  sync imports calls in terms of the parent's `async` imports.
 * add a `strict-callback` option that adds extra trapping conditions to
   provide the semantic guarantees needed for engines to statically avoid
   fiber creation at component-to-component `async` call boundaries
@@ -1391,9 +1393,6 @@ comes after:
   `shared`
 
 
-[wasmio-2024]: https://www.youtube.com/watch?v=y3x4-nQeXxc
-[wasmio-2025]: https://www.youtube.com/watch?v=mkkYNw8gTQg
-
 [Color]: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/
 [What Color Is Your Function?]: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/
 [Weak Memory Model]: https://people.mpi-sws.org/~rossberg/papers/Watt,%20Rossberg,%20Pichon-Pharabod%20-%20Weakening%20WebAssembly%20[Extended].pdf
@@ -1426,6 +1425,7 @@ comes after:
 
 [AST Explainer]: Explainer.md
 [Canonical Built-in]: Explainer.md#canonical-built-ins
+[Component Invariant]: Explainer.md#component-invariant
 [`context.get`]: Explainer.md#-contextget
 [`context.set`]: Explainer.md#-contextset
 [`backpressure.inc`]: Explainer.md#-backpressureinc-and-backpressuredec
@@ -1463,7 +1463,6 @@ comes after:
 [Binary Format]: Binary.md
 [WIT]: WIT.md
 [Blast Zone]: FutureFeatures.md#blast-zones
-[Reentrance]: Explainer.md#component-invariants
 [`start`]: Explainer.md#start-definitions
 
 [Store]: https://webassembly.github.io/spec/core/exec/runtime.html#syntax-store

design/mvp/Explainer.md

@@ -2893,14 +2893,17 @@ start being rejected some time after after [WASI Preview 3] is released.
 
 ## Component Invariants
 
-As a consequence of the shared-nothing design described above, all calls into
-or out of a component instance necessarily transit through a component function
-definition. Thus, component functions form a "membrane" around the collection
-of core module instances contained by a component instance, allowing the
-Component Model to establish invariants that increase optimizability and
-composability in ways not otherwise possible in the shared-everything setting
-of Core WebAssembly. The Component Model proposes establishing the following
-two runtime invariants:
+Component validation rules only allow a component to import and export
+component-level functions, not Core WebAssembly functions. Because component-
+level functions can only be produced or consumed by Canonical ABI [`lift` and
+`lower` definitions](#canonical-definitions), which essentially define
+[trampolines] executed at runtime on all incoming and outgoing call paths, the
+Component Model can define and enforce (at runtime, with traps) invariants that
+component authors can depend on. This is analogous to the invariants provided by
+a traditional Operating System to user-space code running inside a process.
+
+In particular, the Component Model maintains the following invariants:
+
 1. Components define a "lockdown" state that prevents continued execution
    after a trap. This both prevents continued execution with corrupt state and
    also allows more-aggressive compiler optimizations (e.g., store reordering).
@@ -2910,13 +2913,25 @@ two runtime invariants:
    implicitly checked at every execution step by component functions. Thus,
    after a trap, it's no longer possible to observe the internal state of a
    component instance.
-2. The Component Model disallows reentrance by trapping if a callee's
-   component-instance is already on the stack when the call starts.
-   (For details, see [`call_might_be_recursive`](CanonicalABI.md#component-instances)
-   in the Canonical ABI explainer.) This default prevents obscure
-   composition-time bugs and also enables more-efficient non-reentrant
-   runtime glue code. This rule will be relaxed by an opt-in
-   function type attribute in the [future](Concurrency.md#todo).
+
+2. Once a component instance starts executing core wasm code, that component
+   instance cannot be [reentered] via export call or resumption of a separate
+   core wasm cooperative thread until *either* execution returns from the base
+   of the core wasm call stack *or* a core wasm import is called that the
+   Canonical ABI has defined to be a [cooperative yield point]. In particular,
+   calls to synchronously-typed imports as well as asynchronous/non-awaiting
+   calls to `async`-typed imports are *not* cooperative yield points and so
+   generic bindings generators and component authors are *not* forced to safely
+   handle reentrance at *every single* import callsite.
+
+3. Furthermore (extending 2), even when synchronously calling a cooperatively-
+   yielding core wasm import (such as a synchronous/awaiting call to an
+   `async`-typed import or `waitable-set.wait`), unless a component opts in (via
+   "stackful lift" 🚟 or cooperative threads 🧵), core wasm execution inside the
+   component instance is locally *serialized* (via backpressure) so that
+   producer toolchains can continue to use a single global linear memory shadow
+   stack that is pushed and popped in LIFO order while achieving intra-component
+   [event-loop] concurrency via `callback`.
 
 
 ## JavaScript Embedding
@@ -3234,6 +3249,9 @@ For some use-case-focused, worked examples, see:
 [Universal Types]: https://en.wikipedia.org/wiki/System_F
 [Existential Types]: https://en.wikipedia.org/wiki/System_F
 [Unit]: https://en.wikipedia.org/wiki/Unit_type
+[Trampolines]: https://en.wikipedia.org/wiki/Trampoline_(computing)
+[Reentered]: https://en.wikipedia.org/wiki/Reentrancy_(computing)
+[Event-loop]: https://en.wikipedia.org/wiki/Event_loop
 
 [Generative]: https://www.researchgate.net/publication/2426300_A_Syntactic_Theory_of_Type_Generativity_and_Sharing
 [Avoidance Problem]: https://counterexamples.org/avoidance.html
@@ -3318,6 +3336,7 @@ For some use-case-focused, worked examples, see:
 [Resolved]: Concurrency.md#cancellation
 [Cancellation]: Concurrency.md#cancellation
 [Cancelled]: Concurrency.md#cancellation
+[Cooperative Yield Point]: Concurrency.md#blocking
 
 [Component Model Documentation]: https://component-model.bytecodealliance.org
 [`wizer`]: https://github.com/bytecodealliance/wizer