Skip to content

Latest commit

 

History

History
83 lines (64 loc) · 3.31 KB

WASI-04-09.md

File metadata and controls

83 lines (64 loc) · 3.31 KB
Raw

WASI logo

Agenda for the April 9 video call of WASI Subgroup

  • Where: zoom.us
  • When: April 9, 16:00-17:00 UTC
  • Location: link on calendar invite
  • Contact:

Registration

None required if you've attended before. Email Dan Gohman to sign up if it's your first time. The meeting is open to CG members only.

Logistics

The meeting will be on a zoom.us video conference. Installation is required, see the calendar invite.

Agenda items

  1. Opening, welcome and roll call
    1. Please help add your name to the meeting notes.
    2. Please help take notes.
    3. Thanks!
  2. Proposals and discussions
    1. Moving to a CG-style phases process: WebAssembly/WASI#252
    2. Proxy-wasm
      1. Vote: approve for Phase 1 (see previous item)?
      2. Discussion: Next steps.

Meeting Notes

Agenda: https://github.com/WebAssembly/WASI/blob/master/meetings/2020/WASI-04-09.md

Attendees:

Dan Gohman Lee Campbell Yury Delendik Jacob Mischka Andrew Brown Mark McCaskey Matthew Fisher Radu Matei Piotr Sikora Pat Hickey Benjamin Brittain Johnnie Birch

Meeting notes: Moving to a CG-style phases process: WebAssembly/WASI#252 LC: What should be the expectations for wasi-sdk and/or other toolchains when a feature is stabilized? DG: witx support will help wasi-sdk, Rust, and others adopt to new APIs PH: witx is written in Rust, we’re happy for people to implement it in other languages as well. Currently it just emits markdown docs. Wasi-libc has a C header generator. LC: witx becomes the ABI standard, “bytes on the wire”. Clients may have higher-level abstractions. The ABI is where the stability is. Applications may link against different versions of higher-level abstraction layers, but as long as the ABI layer is stable they can run on ABI-conforming implementations.

Proxy-wasm Vote: approve for Phase 1 (see previous item)? Result - approved, unanimous

Discussion: Next steps. Piotr to split out pieces of the spec which can be considered independently.

Discussion: Threads in APIs WebAssembly/threads#138 LC: It’d be nice to start thinking about thread safety and which APIs are thread-safe. BB: Function signatures are typically not sufficient to know if something is thread-safe. LW: The “is shared” predicate needs to be propagated through APIs. Everything is unshared by default. We need a shared attribute for tables, etc., and we’d need to have the shared attribute on functions to make them shared. Without the shared attribute, functions can only be called from one thread. The shared attribute for functions would need to be added in the core wasm spec, and then witx, being based on core wasm, would inherit it. LW: Part of adding threading support sufficient for WASI would require adding a thread-local storage mechanism.

Discussion: mmap LC: What is the short-term plan for mmap? DG: On the web, mmap is complicated by web compat. But WASI can pursue this. LW: FWIW, https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#finer-grained-control-over-memory is a long-standing thing we’ve said we’ve wanted in the wasm CG, but maybe it’s better solved by WASI

LW: I can put together a proposal for a platform-independent mmap interface.