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); }); });
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.
To end the program, you should be using Ctrl + C .
The process. exit() method is used to end the process which is running at the same time with an exit code in NodeJS.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With