Module.callMain and Module.run should always return exit code (regardless of MODULARIZE or EXIT_RUNTIME settings)

[vadimkantorov]

Original title: Retrieve exit status in with -s MODULARIZE=1 and -s EXIT_RUNTIME=0
I build my xetex executable as:

emcc -g -O2 -s MODULARIZE=1 -s EXPORT_NAME=busytex --pre-js $ROOT/texlive.js -s TOTAL_MEMORY=$TOTAL_MEMORY -s ERROR_ON_UNDEFINED_SYMBOLS=0  -s FORCE_FILESYSTEM=1 -s LZ4=1 -s INVOKE_RUN=0 -s EXPORTED_FUNCTIONS='["_main"]' -s EXPORTED_RUNTIME_METHODS='["callMain","FS", "ENV"]' -o $ROOT/busytex.js  $XETEX_OBJECTS $XETEX_DEPS $DVIPDF_DEPS $DVIPDF_OBJECTS $ROOT/busytex.c

And then I call callMain twice:

Module.callMain(['xetex', '--interaction=nonstopmode', '--halt-on-error', '--no-pdf', '--fmt=' + fmt_xelatex,  source_name]);
Module.callMain(['dvipdfmx', source_name.replace('.tex', '.xdv')]);

Each of these runs calls exit(...) internally

How can I retrieve exit status of both runs?

I don't see any error message as in

emscripten/src/postamble.js

Line 406 in 605e3bd

var msg = 'program exited (with status: ' + status + '), but EXIT_RUNTIME is not set, so halting execution but not exiting the runtime or preventing further async execution (build with EXIT_RUNTIME=1, if you want a true shutdown)';

and Module.EXITSTATUS does not exist. onExit / exit / quit_ Module methods aren't somehow being run.

Thank you!

[curiousdannii]

Does setting EXIT_RUNTIME=1 make a difference?

[vadimkantorov]

I'll try, but if I understand correctly, it would prevent me from running callMain the second time, wouldn't it?

[sbc100]

Yes, it would prevent repeatably running callMain, but you probably don't want to be doing that anyway. Most programs expect main to be run with a clean heap and could fail if you call main a second time without re-initializing the program.

If you want to call your function multiple times I suggest you don't use main at all and instead export some other function e.g. _run() which does what you want to do multiple time. Then you will get the return code directly from calling _run()

[sbc100]

In this case you could could call your function mutliMain perhaps? Or better still export a different function for each program.

So Module.callMain(['xetex', '--interaction=nonstopmode', '--halt-on-error', '--no-pdf', '--fmt=' + fmt_xelatex, source_name]); could become Module.xetex(['--interaction=nonstopmode', '--halt-on-error', '--no-pdf', '--fmt=' + fmt_xelatex, source_name]); ?

[vadimkantorov]

Or better still export a different function for each program.

I'm already exporting them. But those functions still use exit under the hood to return. I'll see if exiting the runtime is fast. Do I need to reinitialize the runtime manually somehow before the second function call?

Then you will get the return code directly from calling _run()

Unfortunately it wouldn't probably work because the underlying functions (coming from renamed main functions of xetex and dvipdfm-x) still use exit to return.

but you probably don't want to be doing that anyway.

Yep, I read that it's dangerous, but so far it works okay with xetex+dvidpfm-x

[sbc100]

Interesting. Yes ideally you would restart the runtime with each call... I doubt it will take long to do that. If it does prove too slow and you programs clean up enough after themselves then it might be possible to keep the runtime alive, but you would need to be sure there were zero memory leaks or global state left around after each run.

In that case you might want to consider overriding exit to do something different? You could define you own exit() function in C or in JS to do whatever you want.

[vadimkantorov]

In that case you might want to consider overriding exit to do something different? You could define you own exit() function in C or in JS to do whatever you want.

I had a crazy idea of turning exit(...) in a coroutine-like mechanism that would kick off the next program in the chain (or some dirty tricks with longjmp). But that's for later times :) So I was looking first of the simpler step of retrieving the exit status from JavaScript. It seems that the EXIT_RUNTIME=0 case may also store exit status with simple JavaScript pre/postamble modifications in emscripten itself

Is there a way to reset a runtime by dumping a heap / stack before the run and resetting them after the first run?

I'm also afraid that the browser would re-download the large wasm/data files even if the same program is re-run because of #12212

[sbc100]

Yeah ideally you would be able to avoid wasm download to compilation and just provide a new memory/table/instance and restart the runtime. I'm not sure we support that though. @kripken might know

[vadimkantorov]

Also, overriding exit in C requires -f-no-builtins flag (Maybe easier to override in JavaScript?), not sure if emcc supports it. Ideally, Emscripten would save the exit code into Module.exitstatus or sth similar, regardless of how exit was called and if runtime was terminated or not

[kripken]

I'm already exporting them. But those functions still use exit under the hood to return.

One idea might be to implement exit yourself, stashing the code somewhere and just exiting from JS (with a throw etc., like the main loop does). Then the runtime is not exited and you can keep calling other exports.

Yeah ideally you would be able to avoid wasm download to compilation and just provide a new memory/table/instance and restart the runtime. I'm not sure we support that though.

There was an attempt to cache the compiled Module, see #11379

There might be a better way to do that, if someone has time to look into it.

[vadimkantorov]

One idea might be to implement exit yourself, stashing the code somewhere and just exiting from JS (with a throw etc., like the main loop does). Then the runtime is not exited and you can keep calling other exports.

Can I do this by just overriding Module.exit or Module._exit in JavaScript?

For now, I can imagine it by doing sth like (requires building with -fno-builtin-exit) in native code:

void exit(int status)
{
  EM_ASM({ throw new ExitStatus(status); })
}

Can I do same in pure JavaScript?

[sbc100]

I believe to do it in JS you would need to using --library-js .. but yes you should be able to it that way if you like.

[vadimkantorov]

https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html?highlight=library#implement-a-c-api-in-javascript ?
https://github.com/evanw/emscripten-library-generator : "strange, undocumented library format " :)

[curiousdannii]

You can also use the --wrap linker flag to wrap (and replace) a standard function. But it's possible that intercepting the call to exit might leak memory if it prevents cleanup code from running.

[sbc100]

https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html?highlight=library#implement-a-c-api-in-javascript ?
https://github.com/evanw/emscripten-library-generator : "strange, undocumented library format " :)

It might be strange but its not undocumented: https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#implement-a-c-api-in-javascript

You wouldn't need to use a the generator for a simple library you are writing from scratch.