- Where: zoom.us
- When: January 21st, 5pm-6pm UTC (January 21st, 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
- Closure
None
None
Thomas Lively
Rick
Paul Dworzanski
Ben Smith
Deepti Gandluri
Sam Clegg
Adam Klein
Alex Chrichton
Peter Jensen
Ingvar Stepanyan
Conrad Watt
Azakai
Zho An Ng
Francis McCabe
Ryan Hunt
Yury Delendik
Ross Tate
JP Sugarbroad
Derek Schuff
Lars Hansen
Nabeel Al-Shamma
Jakob Kummerow
Richard Winterton
Emanuel Zeigler
Heejin Ahn
Keith Miller
Thomas Lively seconds.
None.
TL: Summary of what happened there at the last meeting. Posted into chat. I posted that after we talked about it last in the meeting. There was a loose consensus that we should adopt a particular semantics for wait on unshared memories. That is not a radical change, just matches what JS Atomics.wait does. Trap whenever it is executed on shared memory. I have a PR that is linked to from the agenda this PR is updating the spec text in the threads repo for the new semantics. Since we have never taken a vote, we should do that now. I'm looking for a go/no-go consensus vote for the semantics in that PR.
Specifically, wait will trap unconditionally when executed with unshared memories. And notify will return 0 for unshared memories. If that sounds good to everyone, great. If people have concerns, let's discuss.
DG: Do you think we need a poll for having atomic operations for unshared memory?
TL: It was clear consensus that we should do that. I'd like to frame this poll on the PR in general. It also includes RMW, read/write atomic operations too.
DG: The poll here is to allow all atomic operations on unshared memory. wait will trap, notify will return 0. Any objections are more discussion?
| SF | F | N | A | SA |
|---|---|---|---|---|
| 1 | 10 | 7 | 0 | 0 |
poll passes.
JK: I don't have slides. proposal seems straightforward. Currently says that memory must be initially or growable to 2gig. We have requests from partners to push that to 4gig.
Our implementation supports a higher memory limit, but we would like to do this in conjunction with the spec.
I've filed an issue for that, put it in the chat. Any reasons not to do that.
KM: I thought the limits were standardized and recommended, but not mandatory. Is that true?
JK: My reading is that they are mandatory, specifically for the JS API.
LH: My interpretation as well that they are mandatory.
SC: There are some limits that are not mandatory, like maximum function limit.
BS: My interpretation was limits in JS API are mandatory, and standardized across browsers
JK: Allocating 2G is not guaranteed to happen anyway, so in that sense bumping the limit doesn't fundamentally change anything.
LH: You have customers that will request 4G on 64bit applications, and that is likely to succeed.
JK: If that application requires that much, then it will happen, perhaps if it grows to that size.
DG: Is there an interim limit to make progress.
KM: Would it be reasonable if we had a lower minimum size that may not exceed, but the maximum could exceed.
LH: We have an internal limit that is 2G, and will be hard to change. So we don't want to be incompatible.
KM: You're concerned they will have a minimum size that's too large, and then it won't load at all. But it's possible that it will start with a small size, then grow to 4G immediately.
NA: Hello, I'm from adobe. Our applications have files w/ caches. Sometimes stored on disk or other files. The ability to access more memory is performance enhancements, we run better with more memory.
DS: Another thing we've heard is that people that have apps already working, so they want more memory to support larger files.
LH: There could be code out there currently that doesn't work with 3G.
LH: Not currently against this, but concerned that there will be fundamentally incompatible applications on the web.
JS: It's clear that this was intended that an embedder could have less than 32767 pages, so an embedder that couldn't support that would be incompatible right?
KM: On the web in particular, there are difficulties, if it works in one place then they ship it as is, and we get complaints with browser A supporting & B not supporting
JP: Would it satisfy to allow the maximum number to increase? [JK: yes] Then you don't have to deal with instantiation problems.
LH: I don’t know what the minimum limit has to do with anything
JP: Not minimum, but just the initial
LH: I could live with that.
BS: this a a suggestion ffrom a new person to wasm, who noted that there’s a lot of info spread out across repos and in the heads of the participants, so it can be hard for new people to understand why choices were made. They suggested that (similar to some tof the MVP rationale docs, which were really helpful for udnerstanding howthe choices were made) that we should have something similar for proposals. We have something similar with explainers, but it doesn’t have the same level of detail.
BS: Wiuth some of the explainers, it’s clear we want to say X, Y, Z, I”S this something we want to put on the Proposal owners? Nothing concrete, but would like to start a discussion
FM: I’d like to strongly endorse this. I”ve been making a similar doc with the interface types proposal, where we structure the doc between the technical spec, a set of examples, and what I call “choices” that just describes how we made the major decisions. It’s very important for people coming from outside.
TL: I also think it’s a good idea to express rationale in a clear rationale document. I don’t know the direction is where we require this in phases.md as a hard requirement for all proposals, it could get stale where we add a rationale but it’s not updated. Setting a mandate might not always work - should this be more of a cultural change? How much detail is too much detail?
BS: it might be like where we suggest that people write an overview with some rationale is a good place to start.
FM: It's not just one document. Some bigger proposals will need more than one of these. For example in IT I”ve been drafting one on webIDL. To explain to someone knew why we chose one thing over another, focusing on one particular topic. GC will have this too, where there are several different issues that need explaining. I wouldn’t mandate it with legislation that requires it, but it should be included.
FM: Examples are also important, more people usually learn from examples
JP: It would be beneficial about people working on this proposal, in general it would be good for people to flesh out what the general goals and design rationales of a particular proposal are
TL: this is sort of like having an FAQ. one of the good outcomes would be that we’d have fewer people coming in and reading the spec, and wondering how we came to a decision and then opening an issue to ask about it. I feel like we’ve seen this for several topics.
JP: The design rationale has a very different quality than an explainer document, it would also be good to write down what the rationale is talking
KM: How many of these proposals were just consensus? I.e. like atomics, but for more contentious issues, it may be good to document them
BS: A lot of the time, we already have that information and searching through all of the meeting notes
KM: at the same time I don’t want to put even more burden on the champions, to not only come to the CG but also copy everything out into this, it’s already a lot fo work.
TL: One thing we can do to lessen the load on proposal champions is to have standardized documents, with Rationale, overview, notable polls etc. Proposals need not follow the exact sructure, but proposals can decide what sections make sense as we decide what components make most sense
RW: How about just linking meeting notes/discussions
RT: For GC, we have the overview, design, requested we have a rationale, I have examples of how this makes a difference - there are a lot more examples that we can go into - another proposal we are trying to figure out why something was done, and the reasons are no longer relevant, but not documented anywhere it helps on both ends of this conversation
BS: so it sounds like in general people are happy with the idea of doing something like this, so the question is how do we make this more concrete? Suggesting that we retroactively go back and do this for previous proposals seems like too much, but adopting it going forward seems feasible and people are already doing it. So we just need to find some common ground on what.
FM: As a concrete suggestion, if the proposal is small, then an FAQ is enough, if it’s a proposal like GC, then it will be too long to have in one document. We can even have a whole directory of files - there’s a role for answering questions, there is an audience there, and for any given proposal we have to figure out where to address it
BS: so perhaps a suggestion here would be to take the proposal howto document, and depending on whether its a big proposal or a small proposal, update the howto with a sample template
FM Agrees
TL: I propose that we make a proposal template directory in the form of standard best practices that we can all agree on
BS: I like it, this could live in the proposals rep
DG: so we have the standard proposal template but it’s not clear that we have a formula for the details (e.g. whether it’s a big or small proposal). Should we take this offline for more discussion?
BS: yeah that sounds good.