- Where: zoom.us
- When: September 1st, 4pm-5pm UTC (September 1st, 9am-10am Pacific Daylight Time)
- Location: link on calendar invite
None required if you've attended before. Send an email to the acting WebAssembly CG chair to sign up if it's your first time. The meeting is open to CG members only.
The meeting will be on a zoom.us video conference. Installation is required, see the calendar invite.
- Opening, welcome and roll call
- Opening of the meeting
- Introduction of attendees
- Find volunteers for note taking (acting chair to volunteer)
- Adoption of the agenda
- Proposals and discussions
- Review of action items from prior meeting.
- Proposal for changes in EH proposal for two-phase unwinding support Part 2 + discussions (Heejin Ahn) [30 min]
- Potential poll: Should we make the change?
- Proposal for First-Class Stacks (Phase 0 in design#1360) (Ross Tate) [30 min]
- Closure
None
None
- Adam Klein
- Alex Crichton
- Alon Zakai
- Asumu Takikawa
- Benjamin Titzer
- Ben Smith
- Conrad Watt
- Daniel Hillerström
- Daniel Wirtz
- David Piepgrass
- Derek Schuff
- Francis McCabe
- Heejin Ahn
- Ioanna Dimitriou
- Jacob Mischka
- Jakob Kummerow
- Jay Phelps
- JLBirch
- JP Sugarbroad
- KC
- Keith Miller
- Lars Hansen
- Luke Imhoff
- Luke Wagner
- Manos Koukoutos
- Mitch Moore
- Nick Fitzgerald
- Paolo Severini
- Pat Hickey
- Paul Dworzanski
- Rich Winterton
- Rick
- Ross Tate
- Ryan Hunt
- Sabine
- Sergey Rubanov
- Syvatoslav Kuzmich
- TatWai Chong
- Thomas Lively
- Zalim Bashorov
- Zhi An Ng
Thomas Lively seconds
Proposal for changes in EH proposal for two-phase unwinding support Part 2 + discussions (Heejin Ahn) [30 min]
HA presenting slides TODO(heejin): add link to slides
HA: Follow up to presentation from two weeks ago. Not about 2-phase unwinding itself, but how to change current proposal.
[Audio issues, deferring to later in meeting]
Proposal for First-Class Stacks (Phase 0 in design#1360) (Ross Tate) [30 min]
Ross presenting slides First-Class Stacks (pdf) (pptx)
JS: You have catch resuming, but resuming should receive the stackref but it seems to drop it, is it meant to be resumable?
RT: resuming knows its payload doesn’t have stackref in it.
JS: thought there was always a stackref in it
RT: Look at switch.call, look at this event. There doesn't have to be a stackref there. You can use a switch.call to hand the stackref off to the function, not the event.
JS: in this use case you’re not using switch calls, you should have received a stack
RT: High level is there are two common patterns… yield control and have stackref of yielding stack. Sometimes the yielder knows what to do, sometimes the resumer knows. stack.switch says yielder knows, stack.switch_call says yielding stack has some responsibility.
[back to slides]
JP: It's possible for two promises to interleave each other… multiple promises that resolve out of order.
RT: this is still fine with that, basically you can conceive it as, you have a promise you want to wait for… resume this stack that is storing the f with this value, then keep going
JP: How do you know which stack to actually resume… could be multiple suspended?
RT: this is running under the assumption that C++ is already under, that there is only one stack, another version we have in the writeup with multiple stacks
LI: I think it might just work in browser environment, we use Rust w/ promises to do this. We have event handlers and requestAnimationFrame that runs in background process, they don't seem to have problem interacting, they are both happening on UI event loop in JS. They are not actually happening in parallel so it doesn't seem to have an issue.
JP: makes sense
[back to slides]
LI: Would switch_drop handle destructors?
RT: switch_drop is just basic cleanup, not unwinding. That is written up in the example. This was called at the new root, so there's nothing to unwind.
LI: right now we have extra code for rust promise, if you get to the end the executor drops then assume promise is rejected. We still have to do that, switch_drop won’t do that for us
RT: You there are other things you can do, switch abort, etc. switch_drop is a shorthand.
[back to slides]
CW: How important is it that stackrefs are unique. Can you give a high-level on how that would be enforced.
RT: Not critical, could be either way. We think it's more useful that way. If you can guarantee that it's unique, it has more obvious resource management.
CW: How would it be enforced, don't need to implement a borrow checker....
RT: most instructions in Wasm are already linear/affine, we found a few instructions you can give an affine version of, and you call that, everytime you use get, clears out the old value, make sure no one else grabs it. That’s written in the proposal. That’s the sort of thing we can toggle based on community feedback. This is based on our analysis, we found this to work better- affine is easier to manage in low level language
CW: Makes sense thanks.
HA: Wondering about then/within instructions, multiple times you mention implementing two-phase unwinding using these. My proposal is about using the current EH instructions to implement two-phase handling instructions, so if we use then/within instead, then what is the point of making the changes I'm suggesting?
RT: Haven’t talked about two-phase unwinding yet. Stack inspection is related to that, but is different than what is presented here.
HA: Two different set of instructions, so there's no point in changing if we are deciding to use the other one.
BS: maybe we should talk about this in another venue, question doesn’t sound related to presentation
HA: Will present assuming that we will use the current EH proposal for two-phase unwinding, not stack inspection, so need to understand motivation for stack inspection.
RT: we can revisit stack inspection another time, this is designed such that however we designed EH or stack inspection, they complement each other, no fundamental locking between each other
HA: confusing, but will continue presentation without switching
HA: i have not presented it yet, can’t ask for vote/questions
TL: you should present it first
HA: we have 10 mins only, i cannot finish this, will go as far as I can
[Back to discussion on Ross's slides]
CW: do you think you can implement 2 phase unwind with without changing it
RT: went through a couple of times, not easy without changing it
LI: which instructions are the new one? Answer? Or within?
HA: we are using throw and catch. RT’s stack inspection is using call_stack, which is something similar to throw, and within is something like try-catch. RT’s inspection does not use try/catch/throw, uses different set of instructions. I am confused because… we have respectively different views for the change. I was confused that the current proposal is not extendable, but you don’t want to extend it.
LI: I can understand how redirect_to, can be a nested try instead. But why can't call_stack...
RT: … it looks for a function on the stack that can handle/answer the questions
LI: lumen really needs stack switching, we don’t care about 2 phase unwinding, we use stack switching to switch processes
HA: I wasn't talking about stack switching, I don't think they are related.
RT: fgm and i had a thought, having a stack subgroup. The issue is that, there are a lot of interacting issues, need coordination,need to coordinate inspection, unwinding, etc.
HA: I asked a single question and it wasn’t answered. You said current proposal has to change for 2 phase unwinding. But in other proposals and issues, you clearly want to use stack inspection instructions for 2 phase unwinding. I’m confused why do you even want to see the changes in the current eh proposal. I still want to extend the current proposal myself. That’s my reason I propose my changes, because I thought we were on the same page, I’m not sure about that right now.
RT: your changes make us happy. That’s the important thing.
BT: q on stack switching, switch_call instruction, you can call fn on stack you want to switch you. If that fn throws exception/even that matches the handler on the stack, does that mean you can throw exception on other stack.
RT: yes
JS: you can build stack frames on a different stack, and you can execute over there