Add 02-25 meeting notes (WebAssembly#403)

meetings/2021/WASI-02-25.md

@@ -31,3 +31,101 @@ Installation is required, see the calendar invite.
 1. Proposals and discussions
     1. Discussion: Better error handling in WASI
     1. _Sumbit a PR to add your agenda item here_
+
+## Notes
+### Attendees
+- Lin Clark
+- Dan Gohman
+- Andrew Brown
+- Johnnie Birch
+- Sergey Rubanov
+- Mark McCaskey
+- Peter Huene
+- Radu Matei
+- Luke Wagner
+- Ralph Squillace
+- Pat Hickey
+- Till Schneidereit
+- Mingqiu Sun
+- David Piepgrass
+- Yong He
+
+**Dan Gohman:** Overview—errors handled like POSIX with single enum of errno. More APIs in WASI, not feasible to have a single errno enum. Also not reasonable to have a single error type. My expectation for errors is that every library will define its own error types. IT will make it possible for us to define a variant type like Rust’s Result. Does that shape of things make sense?
+
+**Andrew Brown:** Makes sense to me. Errors for wasi-nn are just a totally different sphere than files.
+
+**Dan Gohman:** wasi-libc will still have errno. Errno only describes small set of system errors
+
+**Andrew Brown:** Right now wasi-nn has own kind of error types. What’s changing? Will we just change witx and wiggle
+
+**Dan Gohman:** It’s not a fundamental change. We’re just making what wasi-nn is doing explicit. We’ll also be getting new features from IT which will describe what you’re doing in a better way. Enum with either success or failure, maybe called Expected.
+
+**Andrew Brown:** I think Alex has already made this change.
+
+**Dan Gohman:** Yeah, we wanted to give people a heads up about this plan. 
+
+**Andrew Brown:** One question about the future—will this expected type, in the failure case will you be able to pass things that aren’t just an integer, like strings and stuff
+
+**Dan Gohman:** There is no master plan, but I expect the basic mech will be that you can have any type for errors, with full expressiveness of IT. One caveat, how do we want to handle strings? English isn’t appropriate for all envs. Will need to apply more design thought. Underlying tool won’t have a restriction against that, though
+
+**Andrew Brown:** Agreed. On thing I’ve found with wasi-nn is just having an errno isn’t enough
+
+**Dan Gohman:** Agreed, and that’s a place where tooling might be able to help. We can go down the path of thinkking of enums not just as ints but high-level types
+
+**Luke Wagner:** Along that line, one thing that has bugged me about classical error codes, is sometimes you want to use them for conditionals, and sometimes you just want to debug. Two level nesting of variants? Top level “You called it wrong” and second level provides detail of how you called it wrong.
+
+**Dan Gohman:** Yes, let’s do that. I think that’s totally a good idea to do. Another idea, in POSIX they have system calls that are never supposed to crash. In WASI, we don’t need to be as strict. If you pass a bad pointer into a syscall, it could trap. 
+
+**Pat Hickey:** Yeah, that’s also a kind of a concession for virtualization. Awfully convenient for that
+
+**Dan Gohman:** So that’s the basic vision of it. Any more questions on that level of detail? One thing this does mean, we won’t have unified error handling across WASI. Another thing, we want to go through the APIs and figure out what errors things like the clock apis can return. In practice, the only thing that can fail in a clock is failing to get a clock. Wasi-filesystem will probably be where most of the error codes land. Simplifying property across different APIs. Don’t overload error codes to represent similar but not the same errors. Exception handling is coming. A possible approach is to use unwinding. I think that for WASI, errors work better. If languages want to use unwinding, they can expect errors and unwind. I think using variants instead of exceptions will work well for us.
+
+**Pat Hickey:** The one thing I’ll call out is that proc_exit should be implemented as unwind.
+
+**Dan Gohman:** That’s true. I’m going to claim that proc_exit is special. It might be something that we unwind and then turn into a clean exit status. Then the unwinding becomes an implementation detail. That wouldn’t be a thing that leaks across module boundaries. Often not a good idea for libraries to call exit directly. 
+
+**Pat Hickey:** So we basically get rid of proc_exit as a library function
+
+**Dan Gohman:** So I think what we want to say is return type from main is an error type.
+
+**Pat Hickey:** Yeah, that way we keep types all the way down and don’t turn into bare integer.
+
+**Dan Gohman:** Yeah, so 3 error types. Return values, unwinding, and trapping. Trapping is for program has a bug. Maybe sometimes when return values. ____. And we’ll use unwinding across language boundaries.
+
+**Pat Hickey:** Unlike with errors, we can’t invent new ways to trap.
+
+**Dan Gohman:** Although I wonder if there’s something we could do there. I wonder if it makes sense for wasm to be able to trap with extra info.
+
+**Luke Wagner:** Or there could be a WASI function that says “I’m going to trap, but you can provide me with an error to print”
+
+**Pat Hickey:** You can imagine that a malicious module would do that
+
+**Luke Wagner:** They can do that already. We don’t want wasm to casually be able to catch traps. Because at a very fine granularity. But having a blast zone that allows a set to go away without taking down the rest. I think that belongs at some point of time in wasm’s future.
+
+**Dan Gohman:** yeah, if we add those mechanisms, then programmer errors could just be trapped. 
+
+**Lin Clark:** Best way to collaborate
+
+**Dan Gohman:** Once we’ve fully modularized, each module will audit their own errors. The wasi-libc work will start after the next snapshot which includes those changes.
+
+**Andrew Brown:** Question about sockets. Who’s driving that
+
+**Dan Gohman:** Haven’t heard from them. Don’t know what their status is. Expect that if they don’t respond soon we’ll find someone else
+
+**Andrew Brown:** Who was originally driving it?
+
+**Dan Gohman:** Somebody working for a company called ____. The person who filed it is the person working there.
+
+**Andrew Brown:** Radu, was someone on your side interested in that?
+
+**Radu Matei:** We should probably have a chat at some point. How will that relate to these changes?
+
+**Dan Gohman:** Sockets are the other major user of errno. I expect sockets will have their own errno, and then wasi-libc will have some way to concatenate errnos and turn it into appropriate POSIX errno space. I think that’s basically it.
+
+**Radu Matei:** How about IO Streams?
+
+**Dan Gohman:** We haven’t talked about how it’s going to work with libc. I expect from a POSIX point of view, we might have a bunch of different error codes in wasi-io. Have been talking about wasi-io not reporting very specific errors because it leaks information. We aren’t necessarily going to want to return a lot of detail there either.
+
+**Ralph Squillace:** I think we want to try to figure out, if we help pick up the PR, what’s the best way to move forward without having to reimplement too much. Will reach out to original champion.
+
+**Dan Gohman:** I see wasi-filesystem and wasi-sockets being peers. At a good place for them to work the same way.