- 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: [email protected]
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.