| 00:00 | <jmdyck> | So from the ES spec's PoV, the JS -> wasm interface is some non-standard host-provided functions? |
| 00:01 | <shu> | yes, it is this spec: https://www.w3.org/TR/wasm-js-api-2/ |
| 00:01 | <shu> | how kosher it is idk, i didn't review it |
| 00:06 | <jmdyck> | https://www.w3.org/TR/wasm-js-api-2/#run-a-host-function 's step 5 invokes ES's Call operation, that's how control shifts back to ES semantics? |
| 00:12 | <jmdyck> | So Call invokes the (host) function's [[Call]], which is (say) 10.2.1, which invokes PrepareForOrdinaryCall, which is where the stack manipulation happens. |
| 00:33 | <jmdyck> | ... hm, if I understand correctly, your questions are independent of what the host function does, you're just asking about what happens when the host function returns? |
| 00:42 | <jmdyck> | "my question is: the entry EC is suspended in the middle of wasm doing its own thing in step 2. when we resume, is it reasonable to say that we'll magically return to step 3 and then 2?" Modulo some terminology, and assuming I'm not misunderstanding, yes, I think it's reasonable. |
| 00:59 | <jmdyck> | The ES spec doesn't explicitly consider the case where an ordinary function calls a non-standard exotic function which then calls an ordinary function, but I don't think the spec has a problem with it. |
| 01:01 | <jmdyck> | The spec assumes that the exotic function isn't mangling the execution context stack somehow. (I.e., there are Asserts to something like that effect.) I suppose it could be more explicit about that, but I don't think that would change the answer to your question. |
| 02:39 | <jmdyck> | A different way to look at it: Implicit in the ES spec (and Infra-based specs) is that when algorithm A invokes algorithm B, algo A waits, doing nothing, until algo B returns, at which point algo A picks up right where it left off. (Note that this is distinct from Suspend and Resume, which are verbs that apply to execution contexts, not algos.) |
| 02:39 | <jmdyck> | So when https://www.w3.org/TR/wasm-js-api-2/#run-a-host-function invokes the Call operation (to execute the host function), the understanding is that the 'run a host function' algorithm will wait there, doing nothing, until the Call operation returns, at which point the 'run a host function' will pick up where it left off. |
| 02:41 | <jmdyck> | So it's not magical, it's just the normal meta-semantics of one algo invoking another. |
| 02:43 | <jmdyck> | And I don't think it has much to do with execution contexts (or Suspend and Resume). |
| 02:52 | <jmdyck> | You're right that 2962's clarification of transfer-of-control doesn't help with this question, because the question doesn't involve a transfer-of-control in 2962's sense. But 2962 does eliminate "Suspend" and "Resume" as things you can do to execution contexts, which might help in thinking about the question. |
| 02:58 | <jmdyck> | You ask: "if another spec embeds JS, and is running its own machinery, then removes a JS execution context in the middle of its own steps, do we think that pauses at that point in the embedder's spec's machinery?" What do you think would remove an execution context? |
| 04:38 | <shu> | You ask: "if another spec embeds JS, and is running its own machinery, then removes a JS execution context in the middle of its own steps, do we think that pauses at that point in the embedder's spec's machinery?" What do you think would remove an execution context? |
| 04:39 | <shu> | like, it normatively refers to the 262 notion of EC and Suspend |
| 04:40 | <shu> | A different way to look at it: Implicit in the ES spec (and Infra-based specs) is that when algorithm A invokes algorithm B, algo A waits, doing nothing, until algo B returns, at which point algo A picks up right where it left off. (Note that this is distinct from Suspend and Resume, which are verbs that apply to execution contexts, not algos.) |
| 04:41 | <shu> | ... hm, if I understand correctly, your questions are independent of what the host function does, you're just asking about what happens when the host function returns? |
| 04:44 | <shu> | wasm is trying to write up the spec for JSPI, which suspends the wasm stack |
| 04:44 | <shu> | anyway i'll explain more in the next call |
| 04:45 | <shu> | i think the way they'd currently like to do it is not a good idea, as it imputes too much power to the Suspend verb that allows arbitrary algos to be suspended and resumed in a way we, as 262 editors, ever intended the Suspend verb to be used |
| 10:40 | <jmdyck> | Ah, so when you said "without touching the wasm spec", you meant just the core wasm spec, I thought you meant the wasm-js-api spec too. |
| 10:47 | <jmdyck> | Normatively referring to 262's Suspend is a bit tricky, since 262 doesn't define Suspend (and might have a hard time defining it in a way that's consistent with all uses). |
| 11:08 | <jmdyck> | "what if the host function Suspends its caller EC": Hm, there's at least 3 ECs at play here, for: 1) the JS code that calls the exported Wasm function; 2) the wasm function (which is presumably exotic in ES terms); 3) the host function. So when you say "the host function Suspends its caller EC", do you mean EC #2? But it's already Suspended. If you mean EC #3, what would that even mean? How would you write a JS function to accomplish that? Or are they assuming that the host function (for this purpose) is exotic and they get to define its semantics? |
| 13:25 | <jmdyck> | I've now read about JSPI. It sounds like the host function isn't anything special, it just returns a Promise. And the question has to do with what the JSPI machinery does when that happens. |
| 13:52 | <jmdyck> | Looking at JSPI, I'm confused by the definition of suspending function. It says "Let context refer to the execution context that is current ..." which makes me think this is an ES execution context, but then step 2 is "Traps if context's state is not Active[caller] for some caller", but an ES execution context doesn't have a state component. It's got a code evaluation state component, but the ES spec isn't specific about its nature. So where does this "Active[caller] for some caller" come from? |
| 13:53 | <jmdyck> | I thought maybe Wasm had its own definition of execution context... it has a definition for "context", but that doesn't have a state component either. |
| 17:25 | <jmdyck> | (Asked https://github.com/WebAssembly/js-promise-integration/issues/42) |