The barrier instruction has lexical scope semantics

[titzer]

Hello,

As we're now looking into implementing this proposal in Wizard, we noticed that the barrier instruction introduces a scope for instructions where suspends are dynamically disallowed. This has lexical behavior in that suspension is disallowed after entering the block and then reallowed after leaving the block. Two implementation strategies are afforded: dynamically updating a state variable associated with the current continuation, or stack-frame walking. As stack-frame walking is not necessary for suspension otherwise (only walking over stacks via the parent stack), the barrier seems to add some inherent cost here.

[rossberg]

Yes, the idea was that this sets a flag associated with every stack, which suspend needs to check for each stack it encounters. Indeed that is an extra cost, though we hoped it would be negligible.

Perhaps a better way of providing the equivalent to barrier would be not as a block-like instruction, but as a variation of resume: resume_barrier : t1* (ref cont t1*→t2*) → t2*, which would allow engines to implement it the same way as regular handlers.

That all said, this instruction is the one with the least-clear benefit, and perhaps we should just defer/cut it from the proposal. Our Wasmtime prototype has not yet implemented it either.

[conrad-watt]

Just to pop in here, we've been thinking about shared continuations over in the threads subgroup, and I believe that resume_barrier instructions would fit our needs better than block-level barrier instructions (see WebAssembly/shared-everything-threads#44).

The top-level idea is that there may be situations where execution needs to move from a shared-fixed function where suspension as a shared continutation is disallowed, to a shared-suspendable function where suspension as a shared continuation is allowed. It would be natural to express the boundary between these two worlds through a resume_shared-barrier instruction which marks the "top" of the stack that a shared continuation is allowed to capture. The alternative would be a shared-barrier block instruction, but this would require changing the validation rules within the block's body (to allow a shared-suspendable call from a shared-fixed context that would normally be disallowed).

EDIT: actually, I've realised that the above might be making some unjustified assumptions about the way we would call between shared-suspendable and shared-fixed. I'll continue in the other issue.