Replies: 2 comments
-
Regarding polyfilling, I found an error in the overall strategy presented. The error is due to a broader one with the JSPI design's semantics for traps, so I discuss it in #22. |
Beta Was this translation helpful? Give feedback.
-
Regarding scheduling, the issue presented is caused by using JSPI for something it was explicitly never intended for. JSPI was explicitly design to facilitate interop with synchronous (i.e. non-coroutining/non-stack-switching/scheduler-free) pre-core-stack-switching core WebAssembly programs. The idea is that it adds callbacks onto promises to resume a "synchronous" task once the promise is resolved, using the microtask queue as the scheduler. If, on the other hand, your WebAssembly program is using core stack-switching and has its own internal scheduler(s), then you would interop with promises by adding callbacks onto them that would notify the appropriate internal scheduler that the data is now available and then have that scheduler run whatever and however many tasks it feels is appropriate at the moment. In particular, there is no need for the program to suspend all of its computation in order to add these callbacks; it can just suspend whatever task(s) are blocked by that promise and move on to tasks that are not presently blocked. All of this is expressible with core stack switching and a simple JS API, so there's no need to figure out how to extend JSPI to accommodate these unpredictably varied scenarios. Rather, JSPI should stick to just implementing one pattern for interoping with promises, and we should make sure that pattern is implementable in core stack switching with a simple JS API. |
Beta Was this translation helpful? Give feedback.
-
This is for discussing the questions that arise for integrating JSPI with core stack switching (regardless of the core design), following up on these slides by @fgmccabe.
Beta Was this translation helpful? Give feedback.
All reactions