juj

> The following program does not print anything on linux: Yes, but that is not the program that I wrote. Linux does not have a function `emscripten_exit_with_live_runtime();` along with the...

> Note that `emscripten_exit_with_live_runtime()` is _not_ enough to keep the whole node process alive Maybe not today, but the point here is: what should we intend to design the proposed...

> should emscripten_exit_with_live_runtime keep a node process alive even in single threaded mode? If there are no event handlers, then definitely it is better to quit than to deliberately zombie....

> I don't think this in particular is a bug tbh That is fine. How does one fix the code in the original comment, and how do we carry through...

> However, there are downsides to doing this. It would make it easy to create zombie node processes, which can never do any more work. Would we want to do...

> 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 way that would...

Hmm, so would we consider the following code to be the well-formed best practices snippet for getting started with pthreads hello world? ```c void* thread_main(void* param) { emscripten_out("hello, world!"); emscripten_force_exit(0);...

> I'm not advocating that zombie processes are fine > I imagine this behaviour change will effect quite a few of our tests I don't want to push to propose...

> I think `emscripten_exit_with_live_runtime` is implemented in terms of `emscripten_runtime_keepalive_push` mostly to save on codesize and simplify the amount of state we have to store / check. Yeah I know.....

Do you mean we'd remove the whole `--proxy-to-worker` feature? I am under the impression that there would be active users of that feature still. To me this issue seems to...