Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix MODULARIZE with sync compilation #12650

Merged
merged 3 commits into from
Oct 30, 2020
Merged

Fix MODULARIZE with sync compilation #12650

merged 3 commits into from
Oct 30, 2020

Conversation

kripken
Copy link
Member

@kripken kripken commented Oct 30, 2020

MODULARIZE + WASM_ASYNC_COMPILATION=0, that is, modularize mode but with
async compilation turned off, so that startup is synchronous, should return the
Module object from the factory function (as it would not make sense to return
a Promise without async startup).

Fixes #12647

Copy link
Collaborator

@sbc100 sbc100 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

@kripken
Copy link
Member Author

kripken commented Oct 30, 2020

An existing test used sync compilation, which had to be removed here. I think it never needed it anyhow.

@lourd maybe you can take a look here, does this make sense or am I missing something?

@@ -3274,7 +3274,7 @@ def test_modularize(self):
src = open(path_from_root('tests', 'browser_test_hello_world.c')).read()
create_test_file('test.c', self.with_report_result(src))
# this test is synchronous, so avoid async startup due to wasm features
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this comment no longer true then?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, yes, I'll fix the comment.

@lourd
Copy link
Contributor

lourd commented Oct 30, 2020

Looks fine to me. I'm assuming WASM_ASYNC_COMPILATION is set to 1 by default, or at least set to 1 when MODULARIZE is enabled?

The flag name is kind of confusing, though, since as far as I understand things Wasm compilation/instantiation is always async. I thought the only way to synchronously compile is if you use JS output, not wasm. I'm not sure though after double-checking our wasm compilation documentation. Is WASM=1 MODULARIZE=1 WASM_ASYNC_COMPILATION=0 a functional set of flags?

@kripken
Copy link
Member Author

kripken commented Oct 30, 2020

@lourd Thanks for the feedback!

It is possible to compile wasm synchronously. However, some browsers disallow it for large wasm files.

Yes, the default is async, in all modes.

It's true the flag name is a little confusing now, since the flag is not just for wasm, but also for wasm2js. The name made sense when we also had asm.js output. But maybe the best way to look at it is that wasm2js is as close to wasm as possible, including sync/async compilation.

@lourd
Copy link
Contributor

lourd commented Oct 30, 2020

For sure, thank you for the knowledge!

Re: synchronous compilation, which API would you use to do that? I thought WebAssembly.compile always returns a promise.

@kripken
Copy link
Member Author

kripken commented Oct 30, 2020

@lourd

You can use the synchronous constructors,

var module = new WebAssembly.Module(bytes);
var instance = new WebAssembly.Instance(module, imports);

(not recommended usually, but they have their uses...)

@kripken kripken merged commit 699996c into master Oct 30, 2020
@kripken kripken deleted the syncmodularize branch October 30, 2020 20:17
zbjornson added a commit to cellengine/lmfit.js that referenced this pull request Dec 30, 2022
* `EXPORT_ES6` and `ENVIRONMENT=*node*` requires `USE_ES6_IMPORT_META` to be set.

* `_malloc` and `_free` must be declared as exported functions to avoid removal by the compiler.

* Remove [`WASM_ASYNC_COMPILATION=0`](https://emsettings.surma.technology/#WASM_ASYNC_COMPILATION).

  The current code was broken by emscripten-core/emscripten#12650. Previously, `WASM_ASYNC_COMPILATION=0` would return `Promise<Module>`, but that PR made it return `Module` directly. (Took ages to find the cause of this!)

  Removing the flag to keep it async avoids a breaking change in this library. Node.js v14.8.0 and later support top-level await, so async isn't that ugly. Alternatively, the Node.js version could easily be changed to load synchronously. Node.js has no limit on the size of synchronously loaded WebAssembly modules, unlike Chromium.
zbjornson added a commit to cellengine/lmfit.js that referenced this pull request Dec 30, 2022
* `EXPORT_ES6` and `ENVIRONMENT=*node*` requires `USE_ES6_IMPORT_META` to be set.

* `_malloc` and `_free` must be declared as exported functions to avoid removal by the compiler.

* Remove [`WASM_ASYNC_COMPILATION=0`](https://emsettings.surma.technology/#WASM_ASYNC_COMPILATION).

  The current code was broken by emscripten-core/emscripten#12650. Previously, `WASM_ASYNC_COMPILATION=0` would return `Promise<Module>`, but that PR made it return `Module` directly. (Took ages to find the cause of this!)

  Removing the flag to keep it async avoids a breaking change in this library. Node.js v14.8.0 and later support top-level await, so async isn't that ugly. Alternatively, the Node.js version could easily be changed to load synchronously. Node.js has no limit on the size of synchronously loaded WebAssembly modules, unlike Chromium.
zbjornson added a commit to cellengine/lmfit.js that referenced this pull request Dec 30, 2022
* `EXPORT_ES6` and `ENVIRONMENT=*node*` requires `USE_ES6_IMPORT_META` to be set.

* `_malloc` and `_free` must be declared as exported functions to avoid removal by the compiler.

* Remove [`WASM_ASYNC_COMPILATION=0`](https://emsettings.surma.technology/#WASM_ASYNC_COMPILATION).

  The current code was broken by emscripten-core/emscripten#12650. Previously, `WASM_ASYNC_COMPILATION=0` would return `Promise<Module>`, but that PR made it return `Module` directly. (Took ages to find the cause of this!)

  Removing the flag to keep it async avoids a breaking change in this library. Node.js v14.8.0 and later support top-level await, so async isn't that ugly. Alternatively, the Node.js version could easily be changed to load synchronously. Node.js has no limit on the size of synchronously loaded WebAssembly modules, unlike Chromium.
zbjornson added a commit to cellengine/lmfit.js that referenced this pull request Dec 30, 2022
* `EXPORT_ES6` and `ENVIRONMENT=*node*` requires `USE_ES6_IMPORT_META` to be set.

* `_malloc` and `_free` must be declared as exported functions to avoid removal by the compiler.

* Remove [`WASM_ASYNC_COMPILATION=0`](https://emsettings.surma.technology/#WASM_ASYNC_COMPILATION).

  The current code was broken by emscripten-core/emscripten#12650. Previously, `WASM_ASYNC_COMPILATION=0` would return `Promise<Module>`, but that PR made it return `Module` directly. (Took ages to find the cause of this!)

  Removing the flag to keep it async avoids a breaking change in this library. Node.js v14.8.0 and later support top-level await, so async isn't that ugly. Alternatively, the Node.js version could easily be changed to load synchronously. Node.js has no limit on the size of synchronously loaded WebAssembly modules, unlike Chromium.
zbjornson added a commit to cellengine/lmfit.js that referenced this pull request Dec 30, 2022
* `EXPORT_ES6` and `ENVIRONMENT=*node*` requires `USE_ES6_IMPORT_META` to be set. This changed in emscripten-core/emscripten#17915.

* `_malloc` and `_free` must be declared as exported functions to avoid removal by the compiler.

* Remove [`WASM_ASYNC_COMPILATION=0`](https://emsettings.surma.technology/#WASM_ASYNC_COMPILATION).

  The current code was broken by emscripten-core/emscripten#12650. Previously, `WASM_ASYNC_COMPILATION=0` would return `Promise<Module>`, but that PR made it return `Module` directly. (Took ages to find the cause of this!)

  Removing the flag to keep it async avoids a breaking change in this library. Node.js v14.8.0 and later support top-level await, so async isn't that ugly. Alternatively, the Node.js version could easily be changed to load synchronously. Node.js has no limit on the size of synchronously loaded WebAssembly modules, unlike Chromium.
zbjornson added a commit to cellengine/lmfit.js that referenced this pull request Dec 30, 2022
* `EXPORT_ES6` and `ENVIRONMENT=*node*` requires `USE_ES6_IMPORT_META` to be set. This changed in emscripten-core/emscripten#17915.

* `_malloc` and `_free` must be declared as exported functions to avoid removal by the compiler.

* Remove [`WASM_ASYNC_COMPILATION=0`](https://emsettings.surma.technology/#WASM_ASYNC_COMPILATION).

  The current code was broken by emscripten-core/emscripten#12650. Previously, `WASM_ASYNC_COMPILATION=0` would return `Promise<Module>`, but that PR made it return `Module` directly. (Took ages to find the cause of this!)

  Removing the flag to keep it async avoids a breaking change in this library. Node.js v14.8.0 and later support top-level await, so async isn't that ugly. Alternatively, the Node.js version could easily be changed to load synchronously. Node.js has no limit on the size of synchronously loaded WebAssembly modules, unlike Chromium.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Synchronous access to module compiled with WASM=0
3 participants