- Where: zoom.us
- When: September 4, 4pm-5pm UTC (September 4, 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.
- Proposal for a C/C++ API (Andreas Rossberg)
- Poll: Accept for stage 0
- Closure
None
None
- Adam Klein
- Alex Crichton
- Alon Zakai
- Andreas Rossberg
- Arun Purushan
- Ben Smith
- Ben Titzer
- Conrad Watt
- Deepti Gandluri
- Derek Schuff
- Heejin Ahn
- Jacob Gravelle
- Jay Phelps
- JF Bastien
- Keith Miller
- Limin Zhu
- Luke Wagner
- Peter Jensen
- Richard Winterton
- Sergey Rubanov
- Shiv Kushwaha
- Thomas Lively
- Wouter Van Oortmerssen
- Yury Delendik
Ben Smith taking notes
Derek Seconds
AI(Thomas Lively): Write up discussion about optional vs required features.
TL: 80% written up, will post today. [Link]
AI(Derek Schuff): Figure out relicensing of Binaryen and Wabt.
DS: I have not looked into the relicensing yet. No progress yet.
AR: Some clients want to embed wasm in a non-browser environment. We don’t really have a story for that. No defined interface. AFAIK production systems like v8 don’t provide a real interface for that. V8 has embedding API, but not to wasm functionality. Idea of proposal is to define a c/c++ API agnostic of underlying VM, allows you to embed in black box fashion. One non-goal, it is supposed to be black box. No way to interact with GC, or other complicated ways.
AR: [presents repo]
AR: Has C/C++, has prototype implementation based on v8. Not integrated into v8, but built on top of v8 API. Not the most efficient way to implement it, but it works. For dfinity we have started using this.
AR: Design goals: black box API. C++ version is a bit safer to use, from memory management. C++ uses unique pointers to make that automatic. C version has none of that. Reason is that you can create a binding for C libraries. We use that to create a haskell binding. That is completely manual memory management. Implications are that I try to restrict to language features that are easy to bind to. Some FFI can’t bind struct returns, etc.
AR: Luke suggested that we design everything abstract classes with factory methods. Makes it link-time independent.
BT: Does that mean you could link in two implementations of this API?
AR: All classes are abstract classes, everything is just pointers to methods. Header doesn’t include implementation details.
JF: Why do you have both? Is one implemented on top of the other?
AR: Yes, started with C, but built C++ on top to catch memory errors. Much safer to use.
JF: It’s much easier to create a stable ABI in C, wrapper in C++. When I did this last year I just did C. You really don’t want C++ if you want a stable ABI.
AR: I think it should work, since you’re just programming against a C interface works, though brittle. At some point I found that I had a complete layering in C++. That’s one of the things that we can iterate on, whether the C API is sufficient.
JF: If the user uses is pure C++ and it’s all inline, and the only things we link to are C calls that’s better. Agree that it’s easier to use C++ API. I doubt that webkit would ever expose a C++ API, but already has C APIs.
AR: In principle we can do this, I found it easier to get it working this way.
WVO: Sometimes people who consume pure C libraries don’t want to have to link to C++.
AR: But the engines are all C++
WVO: True
BT: Current engines are implemented in C++
AR: Yes, there’s no reason you have to implement one in terms of the other. You could do both. Maybe just expose C API, maybe wrap the other way. Maybe good idea to have wrapping in both directions so not everyone has to redo them.
TL: It seems like that having two official APIs, one in C and one in C++. Why not have an official rust, haskell one. Just have the C API. Not C++ API that is not as official as the C API, but similar to rust.
AR: Could argue that C++ is on the same level as Rust. Not sure about how that works with the standard.
AR: One advantage of C++ one is that the interface is easier to read. C++ one looks like this. Boilerplate to define vectors. Class that defines Egnine. Class that define Store. Store is an isolated Store, every object is tied to a store. Each store is tied to a thread. Similar to isolate in v8. You can use threads but you have to create separate stores for each thread. There are types (globals, functions, tables, memories). There are Values. Tried to anticipate reference types, makes it a bit trickier to handle API. You can only move reference type, not copy or assign. Tricky to get right in C API.
AR: [Module] So these look more or less like what you expect from the JS API. I recently added a share() function to give a way to share a module between threads without having to serialize them. V8 serializes in this case.
BT: You can now share the modules in v8.
AR: Also has functions, instances, and other types you expect. C API follows the same structure but has super verbose names. For modules, there’s wasm_module_t, all the modules have functions instead of methods.
AR: That’s roughly it. Prototype implementation on top of v8. Some things you can’t do, to call a function you have to go through JS. Prevents being able to use int64. But other than that, things are mostly functional.
AR: A few TODOs. One main thing that came out of discussion w/ Luke. When you call a function you have to allocate some stuff; this already supports multi-return. Might want to change the API so you don’t have to allocate. You always know the types, so you could stack allocate the return values and pass them in.
AR: Any questions? Should this be a stage 0 proposal?
LW: Do you imagine this as an appendix to the standard?
AR: I would assume this is on the same level as the JS API. We would want a separate document for the C and C++ APIs.
JP: What about iterating as a community API before it becomes a standard?
AR: It’s part of the proposal process anyway.
JP: I mean iterating for several years, what works what doesn’t work.
JF: I think this could be ready in a month if we really wanted to.
AR: One reason I don’t want to iterate for years is that clients want to use it now. They want it to be something more solid.
KM: At least historically there is a strong binary API constraint. It would have to be binary compatible.
JF: I think it’s critical to have opaque objects, if you want to have any hope that Apple would ship.
BT: I think the main risk here is future compatibility with future features. And also making sure there isn’t much overhead. I think the functionality is there.
AR: I can imagine that the C API is a bit easier to standardize. It is relying on fewer features. Tried to stick to C++11 to make it easier. It might be nice to use C++17 variants, but then there are the question of exceptions. Some C++ libraries immediately locks you in to certain features. Makes it harder to agree. For C API it is relatively canonical.
LW: Main question to have experimentation is one where the ownership is clear. Make sure that it is a fast API with opaque types.
AR: Started working on this today. Use plain arrays everywhere the type is understood.
BT: One thing I want to ask: sharing memory between C++ and wasm. The embedded wasm memory is hidden state. Being able to map things into wasm memory, that may be something we want to consider. Similar to host bindings, we want to do one layer of unwrapping. We may want something similar for passing across the wasm boundary.
AR: You mean direct access to the wasm heap.
BT: The embedding host has access to the entire address space which has access to the wasm memory inside, so you could share a pointer out from the wasm memory, but wasm can’t access pointers inside the wasm module.
JF: That’s the same as the JS API right?
BT: More like host bindings, convert the types.
AR: The memory buffer class allows you to have direct access to the underlying buffer. So you don’t have memory safety. Defining a shared memory model will be tricky. Probably should not be to formalize this.
JF: I just think it should be possible to do.
AR: I guess what Ben suggested is something like host bindings on top of this. I agree, but I think it would be a separate proposal. This is kind of like the MVP, you can add fancy stuff like that later. Raw functionality is already there. Or should this be there from the beginning?
BT: It may mean that you can simplify things later; pointers into wasm memory etc.
AR: There are a couple of interesting questions for integration: one thing you would like for functions is to call them with their C types directly. Right now you pass in a array of val structs. You can do template magic to do wrapping around that to convert direct C types into val, but it would still go through val struct interface. You cannot type it…
BT: You need to cast it to C++ signature, then you would have API-specific types.
AR: The number of types is infinite, so I don’t know how you would do that with low-level C API.
[AR, BT - discussing how this may work]
LW: If you think of the C API, then you have a C function and a datum. Then the engine creates a stub that can be handed back and cast to the correct type and called directly.
AR: What about return types?
LW: That might be tricky.
AR: Can’t be implemented in C.
LW: JIT can do it by creating machine code.
JG: You could do a vararg function with a format string perhaps.
[discussion about forwarding C types to wasm]
JF: You can see how this works with the implementation I made.
Poll: Accept for stage 0
[unanimous consent]
BS: Move into WebAssembly GH? [yes]
AR: Any issues having v8 implementation in there?
JF: Now, it’s just an example so that should be OK.