- Where: zoom.us
- When: November 13, 5pm-6pm UTC (November 13, 9am-10am Pacific Time)
- Location: link on calendar invite
- Contact:
- Name: Ben Smith
- Email: binji@google.com
None required if you've attended before. Email 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.
- Rename memory.drop and table.drop
- Revisiting the edge-case semantics of wake
- Closure
None
None
- Adam Klein
- Alex Crichton
- Alon Zakai
- Arun Purushan
- Ben Smith
- Ben Titzer
- Conrad Watt
- Dan Gohman
- Deepti Gandluri
- Derek Schuff
- Francis McCabe
- Jacob Gravelle
- Jay Phelps
- Keith Miller
- Lars Hansen
- Luke Wagner
- Michael Holman
- Mike Rourke
- Pat Hickey
- Richard Winterton
- Sam Clegg
- Sergey Rubanov
- Sven Sauleau
- Thomas Lively
- Wouter Van Oortmersson
- Yury Delendik
Lars seconds
JP: I like drop_segment. It keeps it under the same table label.
AR: Bikeshedding but I would call it data.drop and elem.drop or table.drop_elem memory.drop_data. No strong preference
LW: Nice symmetry with data and elem, those are the things you’re dropping.
BS: [Trying to find consensus]
JP: Would like it to stay under table if it affects tables.
AR: But it doesn’t.
BT: I had another bikeshedding discussion. Dropping passive/active and renaming to autoload for active.
AR: What’s the opposite called?
BT: Absence.
BS: Yeah active/passive is not great, but else would we call it. Don’t like noautoload.
LW: The text format can have “auto” and nothing otherwise. Or maybe use lack of init_expr as passive.
LH: Things are becoming ambiguous in the text format already with multiple tables, I don’t think we should push our luck.
BS: The default now is active, so you want to keyword for passive.
BS: Seems like there’s not a lot of interest in bikeshedding, let’s follow up on GH issues.
[Conrad presenting slides] https://drive.google.com/file/d/1h4p5ZJoI2O38SZPu0pMoJTdsOxHDBMv0/view?usp=sharing
AR: This is not just for the spec semantics. It removes an edge case. In realistic cases you can UINT32_MAX. In unrealistic cases you shouldn’t use anyway, because it would trap anyway. There’s no benefit from the current case split, so we should simplify.
BT: How do you do this if you want to wake > 232 with these new semantics? Wake in a loop.
CW: Current semantics don’t cover this either.
BT: You could encode this as 31-bit int with another bit for “more waiters”
LH: You can already do this by adding a “num waiters” instruction.
CW: This is an unrealistic case, linux, windows, etc.
LH: This isn’t just OS threads, also asyncWait.
LW: Is it possible to have wait trap instead of wake?
CW: Would we say that the max number of waiters is 232 then?
That implies we that we specify that we can never create more the 232 waiters.
LH: There’s a poor interaction with JS -- they’d have to agree to this limit.
LW: Engine could just do it.
LW: You probably wouldn’t have made 231 waiters, and …
LH: Trapping is poor semantics.
LW: We already have to trap on grow.
LH: grow is single-threaded
LW: memory.grow is multi threaded though.
CW: Whatever we need is going to require more instructions.
Can we use the unsigned semantics given that we’ll have to add more instructions anyway.
BT: The semantics aren’t quite right, don’t want it to be a loop for “all”
[Discussion about resource limits]
LW: table.grow has to stop before the length fits in the i32
AR: Now that you mention it, there is weirdness with table.size, it’s 32-bits which is 1 more than you can index.
BT: You should be able to index the last one, oh you can’t have a full 4G table.
TL: Why don’t we have wake_all and doesn’t return how many it woke.
LH: It’s a ridiculous corner case, and nobody likes any of the solutions.
BS: In the past we punted on these decisions by adding traps. Maybe we should do the same as LW mentioned.
CW: So it sounds like semantics are preventing > 232 waiters, and using unsigned for wake.
BS: Any issue for TC39 that we’re introducing this limit?
AK: This doesn’t seem like an issue for TC39, there are many limits like this already in the spec.
Poll: trap wait > 232 and unsigned semantics.
| SF | F | N | A | SA |
|---|---|---|---|---|
| 11 | 6 | 3 | 0 | 0 |
JP: bikeshedding wait vs notify.
CW: We’re not doing the same as JS, wait takes nanoseconds in wasm, JS uses a float. So it’s different.
AR: I like wake/wait.
JP: I ran into the confusion, in a conference talk and 1-1. It’s easy to misunderstand. Nice to have a different name to have it different from JS, not a big concern for me. Notify is easier.
BT: I’ve never seen wake used before, always seen notify.
LH: Came from the futex interface in linux.
[discussion about TC39 history here]
LW: Oh, so JS renamed it to notify?
BS: Yes, they did it after all browsers unshipped because of spectre.
LW: So it has the benefit of being in alignment with JS and clarity when speaking.
Poll: Rename atomics.wake to atomics.notify
| SF | F | N | A | SA |
|---|---|---|---|---|
| 0 | 15 | 5 | 2 | 0 |
BS: Two people against, do you want to say anything about why?
AR: Already mentioned before (like wait/wake pairing, and no reason to follow JS)
MR: Wasm is it’s own language so it doesn’t need to follow JS.