- Where: zoom.us
- When: April 8, 16:00-17:00 UTC
- Location: link on calendar invite
- Contact:
- Name: Lin Clark
- Email: lclark@fastly.com
None required if you've attended before. Email Lin Clark to sign up if it's your first time.
The meeting is open to CG members only. You can join the CG here.
The meeting will be on a zoom.us video conference.
- Opening, welcome and roll call
- Please help add your name to the meeting notes.
- Please help take notes.
- Thanks!
- Announcements
- Sumbit a PR to add your announcement here
- Proposals and discussions
- Phase 4 advancement requirements for current Phase 2 projects (Lin Clark)
- Blockers for advancing wasi-filesystem to Phase 3 (Lin Clark)
- Updates on wasi-io, with discussion of Short reads versus determinism and What is a push? (Dan Gohman)
- Lin Clark
- Radu Matei
- Piotr Sikora
- Mingqiu Sun
- Sam Clegg
- Andrew Brown
- Till Schneidereit
- Dan Gohman
- Yong He
- Matt Butcher
- Taylor Thomas
- Mark McCaskey
- Luke Wagner
Lin Clark: Because of timing of phase system being finalized in 2019, we didn’t set requirements for entering stage 4 for proposals currently in stage 2. Proposal is for the following requiremenTill Schneidereit: Implemented in 2 engines in production at scale. But this should just be taken as a guideline. At the end of the day, this is a tool for the group to assess the viability of the proposal, so if the group feels confident in the viability of the proposal despite only having 1 implementation in an engine in production at scale, and the proposal has very strong support, then the group can choose to advance it. But the default should be 2. Implementation demonstrates it works in all 3 major operating systems—Windows, Mac, Linux.
Andrew Brown: All of the proposals being championed by Dan, those are in the Node implementation, right?
Lin Clark: I haven’t kept up with whether they are keeping it up to date. I wouldn’t see Node being necessarily the implementation that we use to demonstrate. It could be, but I don’t think it would have to be.
Piotr Sikora: Could you clarify the rule about multiple operating systems?
Lin Clark: I should clarify that each proposal can have its own phase 4 requirements. So if these 3 OSs don’t apply to a particular proposal, then you can decide as you’re going into phase 2 to say “we don’t think this should apply to us”. But for the general case, we want these to be portable across the different OSs, that’s one of the key goals of the WASI work, so that requirement is just to ensure that’s upheld.
DECISION (consensus): Ratified
Lin Clark: Requirements for moving any proposal to phase 3. Really important that there are no custom ABI mechanisms required for WASI interfaces. All should be built on Interface Types interface mechanisms. Any other goals people think need to be completed before we move any proposal to phase 3?
Andrew Brown: What do we mean exactly by custom ABI?
Till Schneidereit: Early on, decision was made that WASI would use interface types for everything about how data types are encoded for things that can’t be represented by core wasm. That hasn’t been the reality for the work in progress as defined in the witx files, but idea was always to transition to IT as soon as it was far enough along. This is about the individual pieces of data exposed in an API, not the shape of the API itself. IT provides the ABI (the type grammar), WASI provides the API.
Andrew Brown: So once IT is integrated with witx, if we write our specs in witx, we should be good, right?
Sam Clegg: Are we saying then that everything is blocked until IT is basically done?
Till Schneidereit: Entire encoding mechanism for the ABI shouldn’t change after a proposal moves to phase 3. Idea is to avoid that kind of situation here
Dan Gohman: Yeah, phase 3 isn’t final in any sense. My understanding is that there is a bit of concurrency, but that IT will be factored so that the parts that WASI needs won’t depend on the parts of IT that are taking the longest time e.g. adapter functions, which aren’t necessary for WASI’s work. WASI only needs abstract type defs and at the very least a simple ABI to map those to. That can be on a different schedule than rest of IT. That’s not ready yet today either, and may not be necessary for phase 3, but probably for phase 4.
Sam Clegg: IIUC you’re talking about parts of IT that map core data types like strings. And we can implement that on an engine that doens’t necessarily support IT, because it’s the mapping down to the Wasm types.
Dan Gohman: Yes, some work to say how we do that, but that’s basic idea.
Lin Clark: Create a project board with issues I’m aware of. [lists issues]. Any other blockers? Take the silence to mean enthusiastic ratification.
Will be looking to do this for more of the proposals over coming months as well.
Dan Gohman: Not in POSIX but in other systems. In posix, have read and write and can return fewer bytes than requested. That can mean end of stream, or stream interrupted, or could mean that the sending side has ended the write. So this is how POSIX works, get less bytes and don’t know why
In wasi-io, idea is to make that explicit. Reader will know based on status why there are fewer bytes returned.
Transform from one stream to another. POSIX doesn’t tell you info you need to know what to do.
In POSIX, if you get a short read, have to assume that you might have more data. Wasi-io can tell you, so you can do fewer system calls.
Push tells you stream is open but work with bytes that you have. Pushes can make sure that data gets pushed all the way through a pipeline without getting stuck in a buffer somewhere. Some amount of non-determinism, but that’s true of POSIX. Only difference is that you don’t get info in POSIX.
Could say that short reads can only happen at end.
Pushes are considered not part of the semantics of the stream.
Radu Matei: So will it be left to implementors of streams to return the push status?
Dan Gohman: Yes, each implementor will have to decide when push happens. This is a relatively minor corner of wasi-io proposal, but interesting because not in POSIX
Piotr Sikora: Why "push" and not "flush", which is more commonly used to refer to this kind of behavior?
Dan Gohman: Comes from TCP. Flush would also work. Don’t have a strong opinion. One idea is that in future that if we can talk to TCP directly, we could go all the way through with push. Wasi-io has a flush function, and the idea is that it can be used to ___ buffering. Reflects reality. If you’re talking to a TCP stream, there’s buffering happening in between. SSH is one use case for push.
Piotr Sikora: Is there a use case for having force push? Pushes force end-to-end like TCP flag you mentioned, vs a hint where transformations along the way can decide.
Dan Gohman: This is intended to be a force push.
Piotr Sikora: In your example, said it could be buffered along the way
Dan Gohman: Good point. Useful to take a stream to direct to a file and then redirect back, in which case the file doesn’t keep the pushes.
Piotr Sikora: Not sure.
Dan Gohman: Same. This is very early stage.