- Where: zoom.us
- When: September 18, 4pm-5pm UTC (September 18, 9am-10am Pacific Time)
- Location: link on calendar invite
- Contact:
- Name: JF Bastien
- Email: [email protected]
- Name: Ben Smith
- Email: [email protected]
None required if you've attended before. Email JF Bastien or Ben Smith 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.
- Closure
None
None
- Alex Crichton
- Alon Zakai
- Andreas Rossberg
- Arun Purushan
- Ben Smith
- Dan Ehrenberg
- Francis McCabe
- Jacob Gravelle
- Jay Phelps
- Keith Miller
- Limin Zhu
- Luke Wagner
- Michael Holman
- Mike Rourke
- Nick Fitzgerald
- Pat Hickey
- Richard winterton
- Sergey Rubanov
- Thomas Lively
- Till Schneidereit
- Tyler McMullen
- Yury Delendik
Ben takes notes.
BS: Discussing how to make the CG meetings more inclusive
TL: I’ve not been around for a lot of the context. Sometimes discoverability for the decisions is difficult. Past notes are hosted, but it is hard to search. Wondering if we make it easier for people to discover context, if that would help get people up to speed.
JG: Maybe a tagging system using GitHub?
TL: I like this idea, but may require splitting up notes.
JP: A couple of the TC39 proposals, they’ll create a FAQ/discussion doc, which they’ll update with conversations and discussions. A lot of the tc39 proposals get really complex, repeated questions. I don’t know if that applies here to us, but it would be useful to distill common topics and backstory. I have questions about things like that -- I haven’t dug in super deep, but it would be useful to have decisions like that.
SR: Would be good to have something similar to https://github.com/tc39/proposals
TL: It’s nicer to have some way to watch without having to watch the entire design repo.
DE: It could be helpful to have status updates from ongoing repos. It seems like design discussions take place somewhere else.
AR: Some proposals are maybe just not making much progress. Some are just blocked on engine implementation.
DE: Maybe just go through proposals and talk about them, people can maybe help with implementation
FM: Is there an owner? [BS: yes] maybe they should be pushing it. Maybe not scalable.
DE: Sometimes difficult for that to happen in a committee like this.
DE: Another topic: Allow optional asynchronous steps after instantiation?
What this patch does: when different webassembly implementations go off to do more work later. They need to yield to the event loop -- JSC differs from some other browsers. This patch removes some queueing. We discussed this some in issue 741. Keith Miller brought this up in IRC, from 6 months ago. I was delayed in rebasing and relanding.
Any opinions about this PR?
JP: Looks Ok at first glance.
DE: If your a developer, this might matter to you because it says when an event loop turn will happen. It basically says use instantiateStreaming instead of these, if you use another API it will take a pause at a different time.
BS: Emscripten already calls instantiateStreaming and falls back to instantiate, so many developers may not even know. [NF: wasm-bindgen does this too]
LW: What is the net effect here?
DE: It removes some event turns and adds some different ones.
When instantiating a module it would queue a task, but now it optionally enqueues task. WebAssembly.instantiate.
LW: And that’s observable because instantiate calls the start function.
KM: I think that wasn’t in the spec before, it used to be in the same turn, but that’s too constraining. We took advantage of the fact that we had a turn there.
DE: I think that’s the main change.
KM: I think there’s a risk for optional turns, then people implement whatever Chrome did, and then everyone else has to follow.
DE: It’s observable, but I haven’t written tests for this
LW: Bumping a counter during each state.
DE: You can overload promise.then, but what makes this difficult is all the different possibilities and optionality. I just wanted to document the shared practice and leave it at that.
LW: Maybe this should be fully defined and then specify that.
DE: We would have to come into agreement then.
LW/KM: We just specify when a turn happens.
DE: We could say that they all have to take a turn in the event loop.
KM: Promises will be optimized since people will be using them anyway, so I’m not too worried about additional turns.
DE: They happen at a different layer, in the DOM instead of in JS.
KM: At least in JSC and WebKit, this is just two queues in the same run loop. Agree that it’s more work, but I’m not sure how much it really matters.
DE: Two different ways we can go forward here. Encode the current practice, or try to get engines to align.
JP: Is the import object live?
KM: Unclear. JSC currently does it on the same turn as the start function.
LW: It makes sense that messing with the import object is at the same time as the start function, but not the same turn as WebAssembly.instantiate.
JP: How will this impact -- if you synchronously instantiate. If you are not using a start function, and your own convention. How does that work?
KM: All the engines in the sync compilation will just block.
JP: In the synchronous instantiation this doesn’t apply, OK.
DE: Great this is good direction, thanks!