Francis McCabe
Francis McCabe
Can you explain a little more? Francis On Mon, Dec 6, 2021 at 3:30 AM Dmitriy ***@***.***> wrote: > @fgmccabe do you have any news about it? > Looks like...
I can try looking into this. It 'smells' of an integration issue. Can you try an experiment for me? Use 'unsafe-eval' instead of 'wasm-unsafe-eval'?
There has been a separate, yet related, effort to incorporate wasm-unsafe-eval into Chrome's V3 Extension manifest. The default CSP there is script-src: 'self', as you suggest. It is permitted to...
It is definitely NOT intended that stack switching in any guise will be permitted to capture JavaScript frames.
V8 checks for this by using a counter on the boundary between wasm and JS.
Note that the scenario above was possible in the current/old JSPI design: by passing Suspender objects to JS & back. There are also simpler so-called sandwich scenarios which are also...
The 'may not capture JS frames' is a hard requirement from TC39. Independent of the actual form of stack switching. do Currently, in V8, we do 'switch back' for all...
@conrad-watt "All (non-async) JS is assumed to be "non-suspendable", ..." This is probably false. Because, as you identified before, allowing wasm to suspend can lead to JS being suspended.
I misquoted, it was actually: "and all Wasm is assumed to be "suspendable", " that is false. As you noted, we will likely have to go through JSPI to access...
@conrad-watt Regarding "should the JS promise at the boundary in the first thread resolve, and if so, how should the promise be kept alive if its only root comes from...