Open titzer opened 5 months ago
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.
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 https://github.com/WebAssembly/shared-everything-threads/issues/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.
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), thebarrier
seems to add some inherent cost here.