Sign Up

Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.

Have an account? Sign In

Have an account? Sign In Now

Sign In

Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.

Sign Up Here

Forgot Password?

Don't have account, Sign Up Here

Forgot Password

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

Have an account? Sign In Now

You must login to ask a question.

Forgot Password?

Need An Account, Sign Up Here

Please briefly explain why you feel this question should be reported.

Please briefly explain why you feel this answer should be reported.

Please briefly explain why you feel this user should be reported.

Sign InSign Up

The Archive Base

The Archive Base Logo The Archive Base Logo

The Archive Base Navigation

  • SEARCH
  • Home
  • About Us
  • Blog
  • Contact Us
Search
Ask A Question

Mobile menu

Close
Ask a Question
  • Home
  • Add group
  • Groups page
  • Feed
  • User Profile
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Buy Points
  • Users
  • Help
  • Buy Theme
  • SEARCH
Home/ Questions/Q 6658835
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Editorial Team
Asked: May 26, 20262026-05-26T01:57:35+00:00 2026-05-26T01:57:35+00:00

Since many node.js scripts follow a pattern of doing something asynchronously (example below), how

  • 0

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);
  });
}); 
  • 1 1 Answer
  • 0 Views
  • 0 Followers
  • 0
Share
  • Facebook
  • Report

Leave an answer
Cancel reply

You must login to add an answer.

Forgot Password?

Need An Account, Sign Up Here

1 Answer

  • Voted
  • Oldest
  • Recent
  • Random
  1. Editorial Team
    Editorial Team
    2026-05-26T01:57:36+00:00Added an answer on May 26, 2026 at 1:57 am

    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.

    • 0
    • Reply
    • Share
      Share
      • Share on Facebook
      • Share on Twitter
      • Share on LinkedIn
      • Share on WhatsApp
      • Report

Sidebar

Related Questions

Since Flash 10 was introduced, many of the popular 'copy to clipboard' scripts out
Since many years a GUI-standard are the menu-bars of applications with menus popping up,
Since I'm sure many people have different standard, I've made this post a community
Since upgrading to 2008 I and many people here have noticed that randomly VS
How many ServiceContracts can a WCF service have? Specifically, since a ServiceContract is an
I need to use a many to many relationship in my project and since
Whats the correct LINQ to navigate to the end leaf node of the following
I'm programming a project with plugin support. Since many of the plugins are relatively
I am struggling with this question since I noticed that many functional testing frameworks
Since I started studying object-oriented programming, I frequently read articles/blogs saying functions are better,

Explore

  • Home
  • Add group
  • Groups page
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Users
  • Help
  • SEARCH

Footer

© 2021 The Archive Base. All Rights Reserved
With Love by The Archive Base

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.