alexcrichton left a comment

Now that the component model supports multiple tasks and cooperative threadsrunning concurrently in the same instance, the old model of using a per-instanceflag to track whether a component may be entered no longer works.  Instead ofkeeping track of whether an instance has been entered at all, we must now keeptrack of whether an instance has been entered for each in-progress task.This commit removes `FLAG_MAY_ENTER` from `InstanceFlags`, relying instead on aper-task call stack maintained at runtime.  When the `component-model-async`feature is enabled, we reuse the `GuestTask` stack for this purpose.  When the`component-model-async` feature is disabled, there's just a single stack usedfor the entire store.  Note that these stacks are only updated when crossingcomponent boundaries -- not at every internal call within an instance.Each time we're about to enter a instance from either the host or the guest, wecheck the call stack, and if the instance is already present, we trap.Otherwise, we push a new element onto the stack and later pop it back off oncethe callee returns a value.In addition to trapping on recursive reentrance, we do a couple of additionalchecks for host-to-guest calls, for which we previously relied on`FLAG_MAY_ENTER`:- If _any_ instance owned by the store has previously trapped, we disallow entering that or any other instance owned by the store.- If a post-return call is needed for an instance, we disallow entering it until that call has been made.Note that, for sync-to-sync, guest-to-guest calls, the above process entailssignificantly more overhead than the prior code, which only involved checkingand setting a flag and did not require calling into the host at all.  I intendto follow this PR up with one or more optimizations to reduce that overhead.See the discussion of `trap_if_on_the_stack` inhttps://github.com/WebAssembly/component-model/blob/main/design/mvp/CanonicalABI.mdfor examples of such optimizations.In addition to the above refactoring, this commit does a couple of relatedthings:- When a host function recursively calls back into guest code, we now chain the old call stack to the new one.  This allows us to catch recursive reentrance which may span multiple top-level instances.- Previously, we did not push a new task on the stack for sync-to-sync, guest-to-guest calls, which meant we missed catching some violations of the sync-task-must-not-block-before-returning rule.  Now that we are pushing a new task in that case, we catch all such violations, which means some of the existing WAST tests needed updating.Signed-off-by: Joel Dice <joel.dice@fermyon.com>

Signed-off-by: Joel Dice <joel.dice@fermyon.com>