search

leaningtech / cheerp-meta

Cheerp - a C/C++ compiler for Web applications - compiles to WebAssembly and JavaScript
https://labs.leaningtech.com/cheerp
Other
1.02k stars 50 forks source link

Feature request: JS Promise Integration #143

Closed isaackwan closed 1 year ago

isaackwan commented 1 year ago

Any plans to add support for https://github.com/WebAssembly/js-promise-integration/ please?

alexp-sssup commented 1 year ago

This proposal is not yet fully standardized, but at the current stage we don't believe it to be a good fit for Cheerp (or WebAssembly in general)

  1. Cheerp allows you to interact with JavaScript objects from WebAssembly (if you enable the anyref/externref feature). So it is possible to receive and use Promise objects from JavaScript as they were any other object.
  2. Cheerp generates a combination of JavaScript and WebAssembly and this proposal only "solves" the problem of blocking WebAssembly execution, but it can (of course) not magically block JavaScript code. It could be possible to generated code using async/await everywhere, but we suspect that such a solution might have significant performance impact.
  3. We believe that, in general, these sort of "asymmetric" proposals that only deal with the immediate WebAssembly side of a problem without fully considering the impact on JavaScript code are ill advised and we do not support their standardization.

For all these reasons we believe that, at least as things stand, we will not implement this feature in Cheerp.

fgmccabe commented 1 year ago
  1. JSPI is not 'obligatory': if you have the means to manipulate Promise objects in wasm then 'go for it'. However, this will be a compile-time/coding-time choice: wrapping exports/imports fixes the semantics for those functions.
  2. JSPI is not intended to be the complete story for JS integration: it is specific in nature.
  3. I find comment #3 to be difficult to comprehend. It is, by design, a tightly focused proposal that does not preclude other proposals.

Note that accessing Promise objects from wasm is not likely to be 'smooth' for the foreseeable future.

Note also that there is additional work around bringing stack switching capabilities to wasm. Some of your concerns may be addressed or amplified by that work. Core stack switching is much earlier on in the process at the moment.

yuri91 commented 1 year ago

@fgmccabe The main issue of this proposal in the context of Cheerp is that (afaik) it does not allow to suspend a stack frame that contains JS functions.

It is understandable why (you could use this to wrap js functions and make them suspendable, but the JS committee does not like that), but in Cheerp it is very common to have mixed stack frames, because you can tag your C++ functions so that they are compiled into JS or Wasm.

The result would be difficult to debug runtime errors that appear if you change the implementation details of some function. And detecting these situations at compile time is not really feasible.

fgmccabe commented 1 year ago

Yes, well, we are prohibited from allowing JS frames to be captured in this way. The principal reason is that that would change the semantics of JS itself. And, as you note, it does introduce some 'glitches'.