[RFC] Changes to how "modularization" works in emscripten

[Sam Clegg]

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 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

[Brooke Vibber]

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

--
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.

[Brendan Dahl]

Update on modularization changes:

A new experimental setting "-sMODULARIZE=instance" has landed 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.

[Brooke Vibber]

Cool! Sounds like I will have to make changes to support a lifecycle around a single instance for my codec instantiation case but arguably that's superior in general. :)

I'll prototype this work soon.

-- b

To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/dc8c4405-60ae-4c02-9bf4-92c89408f48an%40googlegroups.com.

[Brendan Dahl]

FWIW, we're not currently planning to remove the current behavior of modularization that behaves like a factory.

I do agree that in most cases using a single instance and then having the lifecycle management within the module is probably more efficient (avoids duplicate wasm instances).

You received this message because you are subscribed to a topic in the Google Groups "emscripten-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/emscripten-discuss/PCRw4ttc6Rc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to emscripten-disc...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CAFnWYTkVYvd1Ht4%3DKG2YVE%2BC4NHwMqSSQKdW%3DSyfZ4oGV3Ug0A%40mail.gmail.com.

[Sam Clegg]

In another step in the direction of more modern modularization I just landed a change that allows the use of `await` inside the module creation function/factory: https://github.com/emscripten-core/emscripten/pull/23157

There is one observable change here which is that `--post-js` code will now run after the module has initialized (and constructors and main) have run.  This is consistent with how things work in sync instantiation mode, but if folks are dependent on the previous behaviour of `--post-js` we can potentially restore it.

cheers,
sam

To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CAONg2ag3eAkNrmWzGHkhA76rva5V%2B%2BBaHYSV3Btqm5HC6VVuDg%40mail.gmail.com.