Ability to shutdown Node in-flight

[gireeshpunathil]

• Version: All
• Platform: All
• Subsystem: uv, core

Scope: C++ applications that embed node as a shared library

Issue: Node's life cycle is designed around the event loop method uv_run that assumes exit only when the last handle is drained from the loop, while the embedder may have a larger life cycle in which node workload may be a small subset. For example, the embedder may want to recycle node in response to a shift in workload / configuration, even while the loop is filled with active handles. Current Node / libuv design does not provide such an on-demand exit route.

Proposal: Define a top level API (such as quiesce) that gracefully shuts down the loop and returns from node::Start().

[mhdawson]

FYI @nodejs/delivery-channels

[mhdawson]

@yhwang FYI as this is likely one of the use cases we'd want to include in our extended testing for the shared library support.

[addaleax]

I have written code for Ayo that does basically exactly this. I’ll try to port it over, especially since I’ve been meaning to do that anyway.

[mhdawson]

@addaleax great to hear :)

[addaleax]

Opened #19377 with most of those commits, would be cool if those who are interested could take a look.

[yhwang]

One of the scenario that I tried to handle before is canceling the long-running javascript execution. And it's a tough case because of the resource clean up. For using node.js as shared lib, the mechanism that we provide to shutdown node may also need to handle this case.

[mhdawson]

Looks like #19377 landed, @gireeshpunathil can you confirm we have what is needed for your original request.

[zeke]

TIL

To quiesce is to pause or alter a device or application to achieve a consistent state, usually in preparation for a backup or other maintenance. In software applications that modify information stored on disk, this generally involves flushing any outstanding writes; see buffering.

[addaleax]

I think it’s not quite enough. We basically still want something that exposes uv_stop() and set a flag on the Environment which indicates that the event loop should stop, right?

I have something similar in my upcoming Workers PR, so I can try to make this happen.

It might also make sense to put this in a larger picture and ask what other sensible exiting modes Node.js could use. Rather than introducing a new functions, we maybe want something like this? (API bikeshedding encouraged)

• process.exit({ code, mode: 'immediately' }): Run no further JS code. Basically process.reallyExit().
• process.exit({ code, mode: 'runExitListeners' }): Like immediately, but also runs process.on('exit') listeners. [Current default]
• process.exit({ code, mode: 'graceful' }): Does not actually call exit(3). Rather, we terminate JS execution and return from the main loop. [This is what process.exit() currently does in my upcoming Workers PR.]
• process.exit({ code, mode: 'quiesce' }): Only calls uv_stop() and sets a flag for indicating that we want to return from the main loop, but returns back to JS. Basically graceful without the execution termination.

[addaleax]

Btw, the big advantage of switching to the graceful variant as the default at some point in the future is that it would allow us to finally solve the issues with async stdio that we’ve been having.

The downside is that that might not play well with addons which don’t expect error handling for execution terminations.

[gireeshpunathil]

• yes, for shutting down Node in-flight, src: clean up resources on Environment teardown #19377 is not enough, we need a top level C++ API that an embedder can use. src: clean up resources on Environment teardown #19377 paved way for shutting down uv loop and mange the complexity from within, common embedders do not have access to it yet.

• @addaleax, process.exit variants do not apply for embedders in general IMO, as those embedders don't want the process to exit through Node.js APIs, but just node.(dll|.so) and its events and resources while continue with the embedder's non-javascript workload.

• agree on the issues with async stdio and necessity for their user-friendly behavior.

[yhwang]

those embedders don't want the process to exit through Node.js APIs, but just node.(dll|.so) and its events and resources while continue with the embedder's non-javascript workload.

+1 . We do need a C++ API to shutdown the Node.js runtime. For now, the node::Start() uses the current thread to run Node.js. Maybe we also need to improve it to run on a dedicated/separated thread. However, this issue is about shutdown but not startup. We can discuss it separately.

And for the process.exit() enhancement, it's nice to have 👍