Sam Clegg

if `emscripten_exit_with_live_runtime` artificially keeps the node process alive it seems like it could only lead to zombie process that do nothing (since no events could be received), but maybe we...

> 1. `emscripten_runtime_keepalive_{push, pop}` should keep the Node.js process alive, regardless of pthreads as it's not tied to them and is useful for any async operations. If we did that...

> Is the above code intended to not be ill-defined? I think one problem is that node and browser and different here in that there is no concept keeping the...

> As [@sbc100](https://github.com/sbc100) said, changing `emscripten_exit_with_live_runtime` to keep process alive would change its semantics from what it is today. > > What I think _is_ worth fixing for ergonomics though...

> I don't think I see how to achieve this in Node.js today, except to create a semaphore, and release it at the end of the pthread, and have the...

> > You could do literally anything to that would keep the node event loop from exiting. e.g. `emscripten_set_timeout_loop(noop, 1000)`. > > Ah heh, I mean achieve it in a...

OK, sounds like we can update `emscripten_runtime_keepalive_push` to also keep the node event loop alive then. I imagine this behaviour change will effect quite a few of our tests (but...

This means that following program will never exit under node: ``` void main() { emscripten_runtime_keepalive_push(); } ``` A tricky edge case might be builds that are compiled with `-sEXIT_RUNTIME=0` (the...

Or are you saying that only extend "aliveness" to pthreads, not to the whole node event loop? That seems like a safer change for sure.

> If user wants to exit with a live runtime without never intending to pop (but rather they want to later imperatively call `exit()` to quit), I think the correct...