-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Barrier instruction #79
Comments
+1 to @rossberg's previous suggestion to accomplish this using a |
I suppose a downside of the |
Thinking ahead to shared suspendable functions, an advantage of a block-scope barrier is that it would allow a shared suspendable function to temporarily hold non-shared references inside the scope of the barrier. It could also allow shared-non-suspendable functions that hold arbitrary non-shared references to be inlined into shared-suspendable callers. This is similar to how |
I've also been thinking a little more about this. If we require a "shared-only" handler/barrier only on the I think this is consistent with a world where we don't need a block-scoped |
I was under the impression that the problem being addressed by some barrier was one of mixing code: in particular, being able to safely mix code generated by a stack switching aware tool with code written before the existence of stack switching. |
Yes, for a plain barrier that has nothing to do with multithreading, that's definitely the primary use case. We're thinking ahead to the multithreaded stack switching use case because in that setting, preventing frames that contain unshared references from being suspended as a shared continuation becomes important for correctness as well, and it would be nice if we could use a similar mechanism in both cases. |
Opinion: a barrier instruction (whether its a block instruction or a special resume handler) has a architectural deficiency from the perspective of this use case. |
I was thinking about this more, and I realized that if a |
@tlively a fused create and resume instruction would probably help with this (or an analogous special-cased peephole optimisation in the engine). |
If you fused cont.new and resume_barrier, you might as well just call the result call_barrier. And then if you wanted to take a page out of the EH playbook to prevent further proliferation of call variants, you might want to make the barrier a block instruction instead. |
My understanding is that by avoiding a block Looking at |
I suspect that the most sensible decision is to leave |
I've removed the |
The stack switching proposal notably does not feature the
barrier
instruction from the WasmFX/typed continuations proposal? The question is, do we want to include such an instruction? Do we have a use-case (in mind)? The WasmFX barrier instruction has previously been discussed in issue #44.The text was updated successfully, but these errors were encountered: