- Where: zoom.us
- When: April 2, 4pm-5pm UTC (April 2, 9am-10am Pacific Daylight 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.
- Discuss issues with js-types proposal (issue 1, issue 2).
- Discuss new PR for Host Bindings
- Replacing Brad Nelson as co-champion with Francis McCabe
- General questions / discussion?
- Any initial thoughts on the open question of whether to depend on Type Imports?
- Poll: rename this feature from "Host Bindings" to "Web IDL Bindings" (and thus the repo along with it)
- Discuss starting a new CG Subgroup for WASI
- For background, see the WASI blog post.
- We propose a Subgroup, to iterate on and eventually standardize WASI Core, as well as other modules in the future.
- Poll: Create a new Subgroup with this charter (based on the Debugging subgroup's charter): https://github.com/CraneStation/wasmtime/blob/master/docs/WASI-proposed-CG-subgroup-charter.md
- Closure
None
None
- Adam Klein
- Alex Crichton
- Alon Zakai
- Aseem Garg
- Ben Smith
- Ben Titzer
- Conrad Watt
- Dan Gohman (DG)
- Daniel Ehrenberg
- David Piepgrass
- Deepti Gandluri
- Flaki
- Francis McCabe
- Jacob Gravelle
- Keith Miller
- Kevin Hoffman
- Lachlan Sneff
- Lars Hansen
- Lin Clark
- Luke Imhoff
- Luke Wagner
- Mark Miller
- Mitch Moore
- Nathaniel McCallum
- Nick Fitzgerald
- Paul Dworzanski
- Peter Jensen
- Sam Clegg
- Shu-yu Guo
- Sven Sauleau
- TatWai Chong
- Thomas Lively
- Till Schneidereit
- Venkat
- Yury Delendik
Luke seconds
AG: brief introduction. We want to be able to reflect the wasm types in JS. So the tools can use it. We want to wrap a JS function webassembly type. We should be able to add the wrapped function into a table. We don’t need to import into a module and export. The other feature is to inspect other things about the module.
AG: It says we should be able to specify the minimum and maximum. We currently use the words minimum and maximum. Right now use initial and maximum, new proposal says min and max which breaks backward compat. OK with that?
DE: Sounds good to me.
AG: Since we’re adding new minimum, proposal says we should be able to add initial or minimum, but not both. But the way things are set up, we can give them both. In that case minimum is discarded. I propose that in case both are given, we should use initial. I believe that is the way forward to not break backward compatibility. Thoughts?
LI: Allowing both … erlang allows both. Both but they don’t have an effect could confuse people.
AG: We’ll have to change a spec test for this.
BS: The issue is you could have already passed in an initial, so it may be that it worked before but now would break.
AK: If you already had a minimum there… the general assumption is that people pass object literals. So there isn’t the expectation that these are filled with random keys.
DE: I don’t understand the exact concern. The assumption when evolving is that you use the initial if it’s there and the minimum if it’s not.
??: It probably should be an error then, because that points to the options might not mean what they think they mean.
LI: Maybe an error if they disagree.
DE: I wouldn’t want it to be an error maybe… asserting that there both equal, I don’t see the point.
LI: Erlang has both things, so it may confuse users.
DE: I don’t feel strongly about this, but this is not something expressible in wasm (shrinking memory). If we did add that capability, it would seem wrong to assert that they are equal. It doesn’t seem to be validation of unused arguments in JS option bags.
JG: It’s confusing if they don’t match.
DE: It seems like the appropriate check is minimum < initial.
JG: Currently doesn’t say that. They’re the same, so it’s confusing. I wouldn’t know which is recognized.
DE: We can continue discussing in issue.
JG: I like validating if they’re not equal. If they’re equal then you validate user intent.
BT: Why adding this name?
AG: The proposal says that it makes less sense when the memory is grown. We need to keep initial around for backwards compatibility but minimum makes more sense.
BT: I don’t see a strong use case for making it complicated.
DE: Follow up on github.
Discuss new PR for Host Bindings
- Replacing Brad Nelson as co-champion with Francis McCabe
- General questions / discussion?
- Any initial thoughts on the open question of whether to depend on Type Imports?
- Poll: rename this feature from "Host Bindings" to "Web IDL Bindings" (and thus the repo along with it)
LW: New PR, follow up from TPAC meeting. Adds new explainer with more detail. It continues with proposal to scope host bindings to WebIDL. Please check it out. If there are general questions here, high-level questions. As an update, Brad Nelson is no longer with CG, so we’d like to have Francis as co-chair. Finally, would like to rename to webidl bindings. Any questions?
[no comments]
BT: should be unanimous consent.
BS: POLL: rename host-bindings to webidl-bindings.
[Unanimous consent.]
- For background, see the WASI blog post.
- We propose a Subgroup, to iterate on and eventually standardize WASI Core, as well as other modules in the future.
- Poll: Create a new Subgroup with this charter (based on the Debugging subgroup's charter): https://github.com/CraneStation/wasmtime/blob/master/docs/WASI-proposed-CG-subgroup-charter.md
DG: We published a blog post a week ago, starter WASI api. We’ve seen support for various languages. WASI is inspired by cloud abi, it uses the capability model of security. We expect it to evolve. The API will be more module. There will be additional modules, so we think it should have a CG subgroup. Any questions?
BT: Is WASI going to look at host references -- adding them to the API. When of the capability security concepts is that you can’t forge them.
DG: Yes, currently we use integers, but we want to use references in the future. Potentially we’ll make the current API a polyfill, with a core with references underneath.
BT: So basically it’s references under the hood.
DG: Yes. The current API uses integers because reference types aren’t available everywhere yet, and it’s friendlier to C-like languages. But we’ll be able to do more in the future.
MM: Can you speak about timeline of anyref proposal?
BT: Landed in v8, but not shipped.
KM: It hasn’t started really at all on JSC. For how long it would take, not sure.
LW: Mostly the work is adding stack maps.
LH: We’re done except for table.fill. Don’t have function types, we are not planning on immediately adding them either.
KM: You need stack maps for GC? We just scan the whole stack
LH: Yes
MM: What is the spec progress of reference types? [phase 3]
KM: Were you hoping to make use of function references?
MM: Both. Do object pointers lead to function references? I haven’t followed what’s up with object pointers. I assumed reference pointers.
LH: You can reference a function from JS, and you can invoke it that way.
MM: What about from one wasm instance to another wasm instance? Can you pass something through the call interface from one wasm instance to another, such that the receiving wasm instance can invoke in the namespace where it created, not called.
LH: You can do that, we don’t plan to support the function reference type or func.call yet. But if you can store that in a table, then you can store it in a table, and use it that way.
MM: I’m assuming a case where two wasm instances are not sharing a memory or a table.
LH: In the case of tables you can choose that, you can have shared and private tables. You aren’t not forced to.
MM: What’s the calling convention, such that a caller can dynamically give access to a given function. Sounds like they have to have a table that share.
LH: You have a private table, you use table.get to get the reference to anyfunc, you pass it around as an anyref parameter. But… can you turn the anyref into a function and store it in a table and invoke it? You probably can’t...
BS: I don’t think you can because you need to downcast.
BT: You can declare a table of type anyfunc/funcref.
LH: The reference type proposal has this, but we chose not to implement it.
BT: I think we implemented all of this.
LW: Easy enough to implement, but it may end up slow.
[some discussion about funcref vs. typed function references]
MM: Reason I bring this up -- as we proceed to define WASI APIs, we should assume working first-class functions that can be passed. Designing APIs around anything else would be more awkward.
KM: Are there any reason they are integers? In C++ you could make them an opaque pointer type.
BT: You could still forge them with reinterpret cast.
LW: The current proposal is a starter, but the real API would be to use reference types. It’s not enough to have void pointers. You can’t do that with anyref. You have to go to i32 at some point. This currently happens on the WASI side, but as things evolve this will go over to the other side.
NM: Some implementations would cause a performance overhead. It would add a translation layer on top of whatever is integer.
DG: The plan is that we have WASI apis -- could have a polyfill for i32, one with references. Some could implement i32 version directly, rather than using references. You can implement it however you want depending.
NM: We would end up implementing multiple APIs there.
BT: One benefit of ref types is that they are unforgeable. Emulator inside emulator. Also gives you automatic reference reclamation, you get GC of file handles for example.
DG: Not clear that all systems want that. Some people want i32 and some want references.
LW: You might want safety…. If I just pass an i32 to a syscall, then I can pass untrusted bit.
NM: You don’t get unforgeability via pointers…
LW: Reference types you can’t forge that way. You can only get them from your own local module.
LI: How does host capabilities interact with WASI. For erlang support, you find the number of logical cores, spin up those. We don’t have a way to ask that currently. Is there a way to do that in WASI, or would it be in wasm proper. Are threads part of wasm or WASI?
DG: Threads are part of wasm, in the threads proposal…
LI: Confused because fork was mentioned in lin’s article.
DG: WASI could define an API for this, has been some discussion about pure wasm threads… [LI: would help us a lot], this could be a path forward for that. We could add a thread create/thread join and use it that way. Then parts could be in WASI platform, thread is an object that would provide fork/join … browers could it too, not sure what that do.
DG: For # of CPU cores. That would differentiate to the embedding, so it would probably be in WASI. It’s meant to be modular though, so we could have APIs for number of cores, and embeddings could decide how to implement that.
LI: For the web embedding, we can’t lock up main thread. We need to have a web-specific way to do that. Is there a way to ask about the main thread, in WASI?
DG: ongoing discussion about that. We could have application modes, a command vs. reactor. Reactor stays present and responds to events. Applications declare via manifest whether which they want to be.
LI: Our current plan is to … [ some description of erlang ]
DG: Reactor has other advantages too, it can be completely off the stack. That concept is very new, we need to work on that going forward.
LI: If any worker wants to interact with DOM API, is there anything to make that transparent? Event dispatch thread for Java in swing, create a runner?
DG: I haven’t thought about this -- we want to have APIs that are generic, policy is handled in libraries and polyfills. Things may be end state… implemented about whether in worker on main thread.
BT: Implemented in rust?
DG: In Rust and currently some C code from CloudABI
BT: Since we are also working on v8 embedding API, can’t we implement this so any embedding could use it?
DG: Seems possible. Other questions and follow-up.
POLL: Create a CG subgroup for WASI
| SF | F | N | A | SA |
|---|---|---|---|---|
| 22 | 5 | 0 | 0 | 0 |
BT: I assume the name of imports is WASI?
DG: currently wasi_unstable for now. Wasm module with no prefixes. We have a special feature in C that allows us to declare this independently from C name. If you want to file issues about this, we have a WASI repo for this. But we’ll add a new repo.
LS: Would we have a module with wasi/module_name?
DG: Not sure what the right name mangling there. But yes, they would be separate names.
TS: Does it make sense to transfer it from cranestation? Or make a new repo.
DG: Probably make a new repo.
TS: Mainly thinking of issues.
LI: You can transfer issues in GH now.
BS: Any other topics?
LS: I remember hearing about a whitepaper on the wasm type system. Is that happening?
LW: Most up-to-date is the GC repo
LS: Heard about this a couple months ago? Not sure.