CABI: redefine reentrance rules in terms of component instance flag

Author: lukewagner

design/mvp/CanonicalABI.md

@@ -123,6 +123,7 @@ class ComponentInstance:
   parent: Optional[ComponentInstance]
   handles: Table[ResourceHandle | Waitable | WaitableSet | ErrorContext]
   threads: Table[Thread]
+  may_enter: bool
   may_leave: bool
   backpressure: int
   num_waiting_to_enter: int
@@ -134,6 +135,7 @@ class ComponentInstance:
     self.parent = parent
     self.handles = Table()
     self.threads = Table()
+    self.may_enter = True
     self.may_leave = True
     self.backpressure = 0
     self.num_waiting_to_enter = 0
@@ -155,26 +157,37 @@ by the host, `None`, in the `parent` field. Thus, the set of component instances
 in a store forms a forest rooted by the component instances that were
 instantiated directly by the host.
 
-Based on this, the "reflexive ancestors" of a component instance (i.e., itself
-and all parent component instances up to the root component instance) can be
-enumerated and tested via these two helper functions:
+TODO
 ```python
-  def reflexive_ancestors(self) -> set[ComponentInstance]:
+  def enter_from(self, caller: Optional[ComponentInstance]):
+    for inst in self.entering(caller):
+      trap_if(not inst.may_enter)
+      inst.may_enter = False
+
+  def leave_to(self, caller: Optional[ComponentInstance]):
+    for inst in self.entering(caller):
+      assert(not inst.may_enter)
+      inst.may_enter = True
+
+  def entering(self, caller: Optional[ComponentInstance]):
+    if caller:
+      return self.self_and_ancestors() - caller.self_and_ancestors()
+    else:
+      return self.self_and_ancestors()
+
+  def self_and_ancestors(self) -> set[ComponentInstance]:
     s = set()
     inst = self
     while inst is not None:
       s.add(inst)
       inst = inst.parent
     return s
-
-  def is_reflexive_ancestor_of(self, other):
-    while other is not None:
-      if self is other:
-        return True
-      other = other.parent
-    return False
 ```
 
+Based on this, the "reflexive ancestors" of a component instance (i.e., itself
+and all parent component instances up to the root component instance) can be
+enumerated and tested via these two helper functions:
+...
 How the host instantiates and invokes root components is up to the host and not
 specified by the Component Model. Exports of previously-instantiated root
 components *may* be supplied as the imports of subsequently-instantiated root

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)
@@ -16,6 +14,7 @@ emojis. For an even higher-level introduction, see [these][wasmio-2024]
   * [Thread Built-ins](#thread-built-ins)
   * [Thread-Local Storage](#thread-local-storage)
   * [Blocking](#blocking)
+  * [Reentrance](#reentrance)
   * [Waitables and Waitable Sets](#waitables-and-waitable-sets)
   * [Streams and Futures](#streams-and-futures)
   * [Stream Readiness](#stream-readiness)
@@ -56,8 +55,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 +119,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 +190,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 +319,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 +488,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
@@ -504,6 +507,24 @@ once the reason for blocking is addressed.
 The [Canonical ABI explainer] defines the above behavior more precisely; search
 for `may_block` to see all the relevant points.
 
+### Reentrance
+
+TODO:
+* mention Component Invariant #2
+* blocking specifically intended to allow reentrance
+* thus, define "reentrance" to only blocked synchronous
+  * sync-typed, or async-lowered async-typed
+  * sync-lowered async-typed = blocking
+  * why useful
+* risk: async recursion => deadlock
+  * specific example: backpressure (below)
+  * lots of other possibilities
+  * so general rule: don't create async recursion dependency
+  * only possible via host or in guest via [donut wrapping]
+  * no well-defined way to rule out and trap; async call stack promising,
+    only captures "causality", not "dependence" (good for observability,
+    bad for catching recursion without false positives)
+
 ### Waitables and Waitable Sets
 
 When an `async`-typed function is called with the async ABI and the call
@@ -662,6 +683,7 @@ without calling the component's Core WebAssembly code. By using a counter
 instead of a boolean flag, unrelated pieces of code can report backpressure for
 distinct limited resources without prior coordination.
 
+TODO: mention component invariant #3 again
 In addition to *explicit* backpressure set by wasm code, there is also an
 *implicit* source of backpressure used to protect non-reentrant core wasm code.
 In particular, when an export uses the sync ABI or the stackless async ABI, a
@@ -1379,21 +1401,20 @@ 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
+* allow function closures to be passed as first-class values, supporting the
+  the "callback" pattern in many pre-existing APIs, including Web APIs
 * allow pipelining multiple `stream.read`/`write` calls
 * allow chaining multiple async calls together ("promise pipelining")
 * integrate with `shared`: define how to lift and lower functions `async` *and*
   `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 +1447,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 +1485,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