Skip to content

Latest commit

 

History

History
83 lines (51 loc) · 4.7 KB

stack-2024-01-29.md

File metadata and controls

83 lines (51 loc) · 4.7 KB

WebAssembly logo

Agenda for the January 29th video call of WebAssembly's Stack Subgroup

  • Where: zoom.us
  • When: January 29th, 17:00-18:00 UTC ( January 29th, 9am-10am Pacific Standard Time)
  • Location: Zoom call

Participants

Francis McCabe Yuri Delendik Daniel Hillerström Ross Tate Alon Zakai Thibaud Michaud Frank Emrich Luke Wagner Ashley Nelson Ilya Rezvov Ryan Hunt Brendan Dahl Thomas Lively Deepti Gandluri Paul Schoenfelder Zalim Bashorov Derek Schuff

Agenda items

  1. Discussion and closing poll on Suspender issue (fgm)

Adoption of the agenda

This meeting was recorded; the recording can be accessed here.

Discussion

RT: We should have a broader discussion, I have slides

FM: Let’s do that after the Suspender object vote

FM: All those in Favor of removing the suspender object:

SF: 7 F: 3 N: 1 A: 0 SA: 0

FM: Liable to incur a fair amount of churn, I hope it’ll be over in a couple of months, but it depends on a lot of things being aligned

RH: We can keep a transitional phase if needed, are you going to OT sometime soon?

FM: Missed this milestone, hopefully the next milestone. There’s a fair amount of consensus within the team that we shouldn’t keep both of them around simultaneously. There’s multiple pieces that need to move. Like I said earlier, this discussion has raised a lot of questions about what kind of guarantees Wasm offers to the developer, in terms of preservation, security, etc. This is not really specific to the stacks subgroup - we could have this discussion in the main CG. We have some time, it would be reasonable to open the discussion here.

FM: Expressing what I think Wasm does for the developer, there is a security guarantee that is focused on preserving the engine - it doesn’t offer more than that to the end user. This is an important criteria to decide what features should be added to Wasm. This can also pertain to opt-in/opt-out - changing the type system will not fly with the CG. Both EH & Stack switching are examples of this - The shared everything proposal does add some annotations to the type - the rationale is that in the case of sharing, its necessary in order to preserve the integrity of the engine, without it updates to threads can tear long values

RH: For JSPI, was there ever a design written up on this? Hard to know exactly what we’re talking about. I have a hard time understanding how that would work.

FM: The idea was that a non-suspending functions cannot call suspending functions - we discussed this but did not write it up. Similar to async in JS, you end up polluting the type space. If you have an Async function, the majority of your callers will be async.

RH: JS functions would not be suspendable, and JS function would not be able to call a suspending function?

FM: There would be an escape hatch, it wouldn’t be directly callable by JS.

RT: There’s two answers, one is that suspendable is guaranteed to succeed, the other option is that suspendable is allowed, but not guaranteed to suspend.

FM: The point about this is that it speaks to this higher level of property that Wasm is offering the developer. For example the JVM aims to have a strong guarantee that a library you will write today will work in the foreseeable future without requiring to recompile it = this property is used quite a bit in the Java space. But this is not the direction that we went in. Personally this is partly a consequence of focusing on C++, being able to see the pointers on the stack.. This isn’t a great situation. IT does eliminate some security guarantees, there are a lot of other security violations that are possible, that are not addressed, we don’t have a clear situation of what we’re offering the current programmer

RH: Different to ensure library compatibility, C++ & Java libraries are different. We assume that an ABI will be built on top of Wasm that provide their own guarantees. There’s only so much we can do in the core spec, because it’s so low level, we can consider providing some guarantees (like read only memory), but hard to go all the way

RT: Issue is harder than that.. There are holes here that we are introducing that do not exist in prior systems

FM: Responding to RH directly, it's true that you can’t make C++ a safe language, this has severely constrained the design of Wasm. My personal objection is that there’s a gap between that reality and the message that people take away. It is what it is, I don’t really think it’s possible to change Webassembly.

Adjourn