Enable using -s EXIT_RUNTIME=0/1 when paired with -s PROXY_TO_PTHREAD=1 option.#10126
Conversation
juj
force-pushed
the
remove_noExitRuntime_EM_ASM
branch
from
d29a1e1 to
854b7fc
Compare
juj
force-pushed
the
remove_noExitRuntime_EM_ASM
branch
from
854b7fc to
7d4b9fd
Compare
|
Hmm, the CI Failed in lsan tests, but oddly when I run locally, the same lsan tests fail in current incoming as well even without this PR. Rebased on top of latest incoming to check if the failure repeats... |
…. Previously PROXY_TO_PTHREAD=1 always implied EXIT_RUNTIME=0, and in this build mode, EXIT_RUNTIME=0 would specify the behavior of what the main browser thread would do after calling __proxy_main(). I.e. the main browser thread should not exit when the internal __proxy_main() function has been called. Users did not have a possibility to do -s PROXY_TO_PTHREAD=1 -s EXIT_RUNTIME=1 builds at all. After this change, -s EXIT_RUNTIME=0/1 now applies to the main() function instead, like one would expect: specifying -s EXIT_RUNTIME=1 means that the application will quit immediately when the proxied main() returns. Specifying -s EXIT_RUNTIME=0 means that the application will continue on executing after the proxied main() returns.
juj
force-pushed
the
remove_noExitRuntime_EM_ASM
branch
from
7d4b9fd to
c11a736
Compare
juj
changed the title
|
Oh, hmm, while debugging this, I realized a better way to do this altogether. Changed this PR to actually add support for |
| // Proceed by running main() on the main browser thread as a fallback. | ||
| return __call_main(_main_arguments.argc, _main_arguments.argv); | ||
| } | ||
| EM_ASM(noExitRuntime = true); |
There was a problem hiding this comment.
how is this change related to PROXY_TO_PTHREAD?
There was a problem hiding this comment.
This EM_ASM line is what used to keep the runtime alive in PROXY_TO_PTHREAD build mode.
| if (detached) { | ||
| PThread.returnWorkerToPool(worker); | ||
| } | ||
| #if EXIT_RUNTIME // If building with -s EXIT_RUNTIME=0, no thread will post this message, so don't even compile it in. |
There was a problem hiding this comment.
What about if the application actually calls "exit()"? Or does -s EXIT_RUNTIME=0 keep the program alive in that case too?
There was a problem hiding this comment.
If you look at the implementation of exit(), you can see that it is a no-op in -s EXIT_RUNTIME=0 builds. (Also calling exit() never posted a exitProcess message)
|
Btw, it might be useful to do less force-pushes in PRs, because it would allow seeing the changes over time (and we squash them at the end anyhow). I'm not sure how the code changed here in the new version? |
|
Ah sorry - yeah, out of habit I tend to force push since we used to have a workflow to preserve commit history from PRs. The original version of the code just force-enabled EXIT_RUNTIME=0 when PROXY_TO_PTHREAD=1 was in effect. (i.e. just did from command line the same thing that the EM_ASM() block achieved), but this new version instead changes the meaning of EXIT_RUNTIME to not apply to the main browser thread, but to the proxied main() thread, so it has same functional meaning as when used in single-threaded builds. |
BTW, for my changes I follow a rebase workflow locally so I almost always have to force push. I can preserve the original commit if you prefer but I also sometime like to squash locally too.. I'll try not to do that with this repo if you prefer. |
…. Previously PROXY_TO_PTHREAD=1 always implied EXIT_RUNTIME=0, and in this build mode, EXIT_RUNTIME=0 would specify the behavior of what the main browser thread would do after calling __proxy_main(). I.e. the main browser thread should not exit when the internal __proxy_main() function has been called. Users did not have a possibility to do -s PROXY_TO_PTHREAD=1 -s EXIT_RUNTIME=1 builds at all. (emscripten-core#10126) After this change, -s EXIT_RUNTIME=0/1 now applies to the main() function instead, like one would expect: specifying -s EXIT_RUNTIME=1 means that the application will quit immediately when the proxied main() returns. Specifying -s EXIT_RUNTIME=0 means that the application will continue on executing after the proxied main() returns.
3 participants
Enable using -s EXIT_RUNTIME=1 when paired with -s PROXY_TO_PTHREAD=1. Previously PROXY_TO_PTHREAD=1 always implied EXIT_RUNTIME=0, and in this build mode, EXIT_RUNTIME=0 would specify the behavior of what the main browser thread would do after calling __proxy_main(). I.e. the main browser thread should not exit when the internal __proxy_main() function has been called. Users did not have a possibility to do -s PROXY_TO_PTHREAD=1 -s EXIT_RUNTIME=1 builds at all.
After this change, -s EXIT_RUNTIME=0/1 now applies to the main() function instead, like one would expect: specifying -s EXIT_RUNTIME=1 means that the application will quit immediately when the proxied main() returns. Specifying -s EXIT_RUNTIME=0 means that the application will continue on executing after the proxied main() returns.