-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
A flag to not use module-level global variables in web-target #3731
Comments
AFAIK audio worklets support dynamic imports for a while now. Which browser are you experiencing this on? |
Chrome and Firefox both throw error of "TypeError: import() is disallowed on WorkletGlobalScope." for the following initialization code (in AudioWorkletProcessor).
Where |
Ah right, I looked it up again, static imports are supported but not dynamic ones. I think in general we should not be using any global variables in the no-modules target, but I didn't look into how that could be done, but AFAIK it should be possible. Generally speaking though, it is considered a bad idea to use |
just now had a related problem in which the wasm object is re-used if, on a single-page web app, you navigate away from the page with wasm and back. a quick partial solution would be to add a way to destroy the wasm object held in the generated module e.g., export function __wbg_reset(){
wasm = null
} that way next time you run the __wbg_init you'll get a brand new wasm object |
Sounds like a B/F cache problem to me. |
A workaround is in #3818 |
Motivation
Lets say a user wants to create an audio plugin system using webassembly which uses a common interface that a plugin must implement in order to load. Currently, when loading multiple plugins using an AudioWorkletProcessor script, 'wasm' variable is set on first call on __wbg_init. This means subsequent loading of next plugin leads to using the already set 'wasm' variable, making it bit challenging to implement such system. Note that AudioWorkletProcessor scripts cannot use dynamic imports, making it hard to get fresh module by for example setting url parameters to bypass cache.
I fixed the problem by wrapping the generated .js file inside a function that returns __wbg_init, initSync and defined Rust types. However, this means I need to redo the modification the module each time it is generated.
Proposed Solution
A flag for web target that allows to load initialize multiple different instances of wasm blobs using the same module. My take was to wrap it inside a function but maybe there is another alternative approach that makes it possible to not break web target api.
Alternative Solutions
In case there is a simple fix that can be implemented using the current codebase, let me know!
The text was updated successfully, but these errors were encountered: