Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How does a node.js process know when to stop?

Tags:

node.js

Since many node.js scripts follow a pattern of doing something asynchronously (example below), how do they know when to stop?

In the following code, how does node determine after processing the writeFile, and registering the callback appropriately, that the process should be kept alive until the callback(s) run?

fs = require('fs');  fs.writeFile('foo', 'cat', function() {   console.log('wrote to foo!');    fs.readFile('foo', 'utf8', function(err, data) {     console.log(data);   }); });  
like image 788
Dan G Avatar asked Oct 08 '11 18:10

Dan G


People also ask

How does Node JS process work?

Node. js runs in a single process and the application code runs in a single thread and thereby needs less resources than other platforms. All the user requests to your web application will be handled by a single thread and all the I/O work or long running job is performed asynchronously for a particular request.

How do you stop a Node JS process?

To end the program, you should be using Ctrl + C .

What does process exit do in Node JS?

The process. exit() method is used to end the process which is running at the same time with an exit code in NodeJS.

Which process event is emitted right before a Node process crashes and exits?

When Node. js exits, it also emits several types of events. One of these is beforeExit , and as its name implies, it is emitted right before a Node process exits. You can provide an event handler which can make asynchronous calls, and the event loop will continue to perform the work until it's all finished.


1 Answers

node keeps track of all outstanding work requests. Your fs.writefile() call creates a work request for I/O and adds your callback to that request. node saves the work request into its tables at the same time it is starting the I/O activity. Your code execution exits when you reach the end of your function. (But your memory/variables/etc. remain)

Later the I/O finishes and node takes the work request out of its tables. It sees the callback attached to the request and so calls that function with the results of the I/O request. Your global data is still around and any variables in closures still exist, so it seems to your code like it never stopped.

If you do nothing more, don't make any more requests, then when you return from your functions node will stop, because then there won't be any remaining requests in the queues.

So node 'knows' to keep running because it tracks active work requests in its tables and won't stop until all queued work is done and those tables are empty.

Please note that "queued work" can include things like waiting for timers or waiting for network data to arrive. You make a request that says "call me here when/if something happens later".

setTimeout() is a work request too (if you squint a bit). With a timer you know something will happen and when it will happen. With setTimeout() only one 'something' will happen. node will make only one call to your callback and then 'forget' the work request. If instead you use setInterval() you have created a persistent work request. node will 'keep' the work request in its tables and will call your callback repeatedly, until you cancel the request.

net.Server.listen() is another work request which is a persistent work request. You don't know when your callback will be called or how many times, because that depends on remote clients connecting to your server. node keeps the work request alive in its tables until you cancel the request.

like image 69
Shenme Avatar answered Oct 11 '22 06:10

Shenme