kripken/emscripten — pull request #1444 by inolen (2013-07-30 00:59:06+00:00)
Title: onload core changes

In revisiting the onload branch I figured I'd cherry-pick the more risky changes so they could be evaluated individually.

The first change was making callMain be more self-sufficient. Currently, preMain is called by run. So if the initial call to _main is disabled, preMain is still called which seems incorrect. Also, callMain will currently initialize the runtime, but it won't exit it. That also seems bad. It seems run should be responsible for aspects surrounding callMain (preRun, postRun, etc.) and callMain should be responsible for aspects surrounding main (initRuntime, preMain, exitRuntime).

The second change here involves stopping callMain and run from returning incorrect exit statuses. Currently, callMain returns an exit status, which is propagated up by run. This exit status is useless however if the application isn't fully synchronous. Instead of trying to return a value, the correct value now always makes it to the new Module.exit function:
https://github.com/inolen/emscripten/commit/52a15b8c6a1f293b55a6c7a20efff3d6ebbc08b4#L1L115
However at this time there is no way to hook into getting that status code (note the TODO comment, it will be added).

Finally, I added Module.exit and Module.abort. Adding Module.exit lets us re-use the exit functionality for both forced-exits through calls to the libc exit, and natural exits when main peacefully returns in callMain.

In the end, this change breaks 4 tests from o1 (two are expecting the "Exit Status: %status" message that's currently not printed until the above TODO is resolved and the other 2 are embind tests). other and sanity run fine.

The embind tests break because `noInitialRun` currently doesn't do what it did previously. Since the runtime initialization has been moved to callMain, the runtime is no longer initialized when noInitialRun is true. I can make `noInitialRun` behave as it did previously, but I'd also be in favor of fixing it to do as advertised and not actually call run initially, however I'm sure that'd break even more tests.

If you'd like to _only_ initialize the runtime for library modules as @chadium mentioned in IRC, we could export initRuntime to be called manually, or perhaps keep noInitialRun's current functionality under a new variable name. Supporting it through the very misleading name of `noInitialRun` doesn't seem right.

Anyways, there are still minor fixes to be made to actually close out issues such as https://github.com/kripken/emscripten/pull/1196, https://github.com/kripken/emscripten/issues/1396 and https://github.com/kripken/emscripten/issues/1378 but they'll be trivial if we can clearly define each step of the startup / exit process.