CODEWITHSUNDEEP
javascriptnode.jsasynchronouscallbackasynchronous-javascript
Milan Poudel
Milan Poudel

Reputation: 792

Are there only some spefiic callbacks that are processed inside the event loopin Nodejs after the call stack is empty?

1.const geoCode = (address, callback)=> {

setTimeout(()=> {
 const data ={
    longitude: 0,
    latitude: 0
}
  callback(data)
  }) 

}

geoCode('John', (data)=>{
 console.log(data)
 })


2. const forecast =(longitude, latitude, callback) =>{

   const url = `https://api.openweathermap.org/data/2.5/weather? 
   lat=${latitude}&lon=${longitude}&appid=ff894a55e90b66e3d6cd4b2bd8ea6509`
   console.log(url);

   request({url, json:true}, (error, {body})=>{
   if(error) {
      callback('Unable to connect to the Internet', undefined)
   } else if(body.error){
      callback('Please try again', undefined)
   } else {
      callback(undefined,body.main)
      
   }

})
}

Hi, I am new to Node.js and having a hard time understanding callbacks,callback queues and how it is processed. My question is what kind of callbacks goes to the callback queue in Node? Does it have to be callback that is inside of node specific APIS,npm packages and web APIs like setTimeOut,request(), to be added inside of callback queue to be executed after the main call stack is empty? or any kind of callbacks goes into the callback queue in node.js?

Upvotes: 0

Views: 660

Answers (1)

jfriend00
jfriend00

Reputation: 707158

Any event-driven item in node.js ultimately has some code that inserts a callback in the event queue at some future time. This can be the built-in items like setTimeout(), setInterval(), networking through the net module, asynchronous file I/O through the fs module, etc... or it can be also be native code add-ons using the add-on API, triggering events and causing callbacks to be inserted into the event queue. This is the crux of how any asynchronous event that occurs sometime in the future works in node.js. Every asynchronous operation uses this same mechanism.

The event loop is actually fairly complex and contains a bunch of different types of queues. There's one for I/O, there's one for timers, there's one for promises. They have different priorities and a certain ordering. Promises, for example, have a higher priority than other types of events. Timers actually work a bit differently than the others, but you can still logically think of them as a set of timers that, when triggered, they cause a callback to get called.

Except for timers, when an event wants to be triggered, some native code somewhere inserts a callback into the appropriate part of the event queue. When the event loop gets around to that particular type of event, it will call the callback associated with that event and execute the Javascript associated with that callback. When that callback returns, it continues with its march around the event loop looking for other events to run the callback for. If nothing is found that's ready to go, it sleeps until something is inserted into the event queue or until the next timer is ready to fire.

Timers use a sorted linked list with the next timer at the front of the list. The event loop just compares the current system time with the firing time for the timer at the front of the list. If it's time (or past the timer) for that event to fire when the event loop gets around to checking timers, then the callback associated with that timer is executed and it's removed from the linked list. If not, the event loop moves on to the other types of events.

Upvotes: 2

Related Questions