- Where: zoom.us
- When: September 15th, 4pm-5pm UTC (September 15th, 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 a new sub-group focusing on stack issues (Francis McCabe) [10 min]
- Closure
None
None
- Adam Klein
- Alon Zakai
- Andrew Brown
- Asumu Takikawa
- Ben Smith
- Clemens Backes
- Conrad Watt
- Daniel Hillerström
- Daniel Wirtz
- David Piepgrass
- Derek Schuff
- Emanuel Ziegler
- Francis McCabe
- Heejin Ahn
- Ioanna Dimitriou
- Jakob Kummerow
- Jay Phelps
- Lars Hansen
- Luke Imhoff
- Luke Wagner
- Manos Koukoutos
- Mitch Moore
- Nabeel Al-Shamma
- Nick Fitzgerald
- Paolo Severini
- Pat Hickey
- Paul Dworzanski
- Petr Penzin
- Rich Winterton
- Rick Battagline
- Ross Tate
- Ryan Hunt
- Sabine
- Sam Lindley
- Sean Jensen-Grey
- Slava Kuzmich
- Thomas Lively
- Vivek
- Wouter Van Oortmerssen
- Zalim Bashorov
- Zhi An Ng
Derek seconds
Proposal for changes in EH proposal for two-phase unwinding support Part 2 + discussions (Heejin Ahn) [30 min]
[Heejin presenting]
LI: How does catch_br interact with unwind, I assume it skips the catch branches, similar to unwind?
HA: we don’t need to consider unwind and catch_br...
RT: I think you can think of catch_br saying reuse the handler, so unwind still uses the same unwind.
HA: we need to consider unwind, because try can have labels, we can consider unwind as a target for catch_br, we don’t need to rename it. It helps us find next frame to search for, if it says unwind, continue the search. Catch_br tells us which to check next, it can be either unwind or catch. In second phase, we have to visit every unwind block. To visit the right sequence of unwind blocks, we need that catch_br.
LI: Yes, that's what I thought. And you addressed my other concern which is that catch_br can branch to another unwind. Combining the catch/unwind names would be verbose.
TL: question about last slide. Where the label corresponded to the function. Is that an extension? You were pointing that the proposed changes allowed for that? Or are you saying we can allow for it in the future?
HA: We need it, without that we don't have any way of redirecting the exception to the caller. It happens not infrequently even now. We're dealing with it on exnref, by adding an extra block that wraps the whole function. We are simulating that with exnref now, so now that we don't have exnref we need a way to do this.
BS: question about rethrow with immediate argument. That can be implemented by branching out of block and rethrowing while still inside the outer try.
HA: possibly. I don’t have a full knowledge of possible future list of things we are going to support. But C++ is not going to use that future. If we have feature we will always set that to 0. We won’t need that immediately. I wasn’t super closely involved with the first version of the discussion, wondering if people who were there remember why this was introduced, or know why other languages think they need it.
| SF | F | N | A | SA |
|---|---|---|---|---|
| 7 | 14 | 7 | 0 | 0 |
Poll passes
(signup form)[https://docs.google.com/forms/d/e/1FAIpQLSfB-QGuZcOokHaaLF_Gl2mF1FVZQZq2LwbGw7U9-x6tmieJKw/viewform]
LH: Why should we not keep these topics in the main CG? What’s the CG doing that prevents it from tackling these issues?
FM: Mostly a question of bandwidth and time, seems like we are often running out of time in the CG meetings.
ID: Is this also connected to the typed continuations proposal?
FM: Yes, that would be appropriate for this meeting. There are a family of efforts that we have interest in.
RT: The form you sent out has bullets instead of check boxes, may want to fix.
FM: I'll fix.
CW: some of the proposals mentioned in the slides seem interesting because they extend how control flow works. Could extensions to exceptions end up interfering with some of this things this sub group will talk about
FM: EH is a potential topic… this isn’t to replace any decision making or discussion point. I would expect that EH would be the sort of thing we will talk about
CW: Is this really a control-flow subgroup then?
FM: could be another way of thinking about it yea.
HA: I think exception handling is related, depending on how which way we take it, maybe only tangentially or significantly. Two-phase unwinding changes things in various ways, and we haven't decided which to go. In theory the overhead is too big, but we could use two-phase unwinding to handle these things. We could extend ...
FM: need to be clear about something, we are not making any particular proposal here. If you wanted to be able to discuss and have more time to talk about EH issues, this is a good place to have it.
CW: It seems like there could be a divergence that discussions would happen in the subgroup and then not filter to the larger group.
RT: other purposes of this group will be to coordinate those sort of things
HA: don’t think EH should be exclusively discussed in that, might have some intersection between EH and stack. E.g. Ross is proposing something related to EH and stack. There are some intersection between these 2, but EH shouldn’t be exclusive to that meeting, agree with that.
LI: There's already overlap between the subgroups and main groups. Debugging for example. Seems to be OK so far.
TL: think this is extra bandwidth on top of what we already have. Meant to be additive, and not detract from the main group.
BS: opportunity for better communication. Perhaps subgroups should take the chance to present to the larger group, to make it clear to larger groups that bigger decisions are made.
FM: From a process point of view, I'm not proposing that the subgroup takes ownership of decision making. If there's a decision to be made, it should be made in the larger group. That should streamline the main groups discussion. If you had a deeper discussion about a topic, then you could make a summary to the main group.
BS: next steps will be to fix the forms…
FM: fixed
BS: have people fill out the form, by the next CG meeting we’ll see
BS: at least 1 meeting will probably be fine