Update on modularization changes:
A new experimental setting "-sMODULARIZE=instance" has landed
<https://github.com/emscripten-core/emscripten/pull/22867> in version
3.1.73. The new output creates a single instance of the Wasm module and
also uses ES module exports for the corresponding exported Wasm and runtime
JS functions. The module also exports a default function for initializing
the module that must be called before any of the named exports can be
called. This style of module is hopefully more similar to what ES module
users expect and should be easier for bundlers to reason about.
An example of using the module:
import init, { foo, bar } from "./my_module.mjs"
await init(optionalArguments);
foo();
bar();
Feedback on the new setting is welcome here or please file a github issue.
On Monday, April 1, 2024 at 4:08:55 PM UTC-7 Brooke Vibber wrote:
> I don't need internals in global scope, but I _do_ need multiple
> instantiation if possible for the demuxers and codecs in ogv.js.
>
> If that's dropped, I'll have to rewrite some C and JavaScript code for my
> internal APIs to support multiple active data streams in a long-lived
> instance with explicit data structure lifetime management, instead of each
> instance being single-use and garbage collected independently. It wouldn't
> a hard blocker, but it would require some refactoring if there's only one
> mode and it's single-instance. :)
>
> -- b
>
>
> On Mon, Apr 1, 2024 at 12:52 PM 'Sam Clegg' via emscripten-discuss <
> emscripte...@googlegroups.com> wrote:
>
>> A few of us on the core emscripten team have been tossing around ideas
>> about how to improve/modernize the modularization of emscripten-generated
>> code.
>>
>> I've created a google doc
>> <https://docs.google.com/document/d/1ccH3NsRQgEc1HXWI_IFAnMbTM0Vn1lP_EhJmdLRzYvs>
>> with
>> comments open to anyone. Please feel free to comment on this document and
>> raise any concerns you have either there or here on this thread.
>>
>> The first step along the way is to improve encapsulation by bringing back
>> the old `-sMODULARIZE_INSTACE` settings (perhaps with a better name). All
>> this setting really does is wrap the emscripten-generated code in a private
>> function context. I'm hoping we can do this without affecting code size
>> in any significant way.
>>
>> Ideally we would make this new mode the default, or even the only mode.
>> However there will likely be some users who are currently depending on the
>> emscripten internally being available in the global scope. So at least
>> initially this will be optional, and perhaps enabled in `-sSTRICT` mode.
>>
>> It would be very useful to know how many folks currently depend on the
>> internals of the generated code being available in the global scope? Do
>> you use emscripten-generated functions or globals without accessing them
>> via the `Module` object? (Note that if you use --closure=1 you already
>> cannot access these internals due to minification, so you won't be
>> affected by this change).
>>
>> cheers,
>> sam
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to emscripten-disc...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2_FWhBnRgKi_33Fw4nkhqFjV_uJKU4gGdSoBZjKf%3DOTwQ%40mail.gmail.com
>>
>> <https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2_FWhBnRgKi_33Fw4nkhqFjV_uJKU4gGdSoBZjKf%3DOTwQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/emscripten-discuss/dc8c4405-60ae-4c02-9bf4-92c89408f48an%40googlegroups.com.
