3

I'm assuming that Node.js continuously listens for events and handles the listener code asynchronously whenever an event is fired.

I have tried defining a custom event using the 'events' module, that is manually emitted in the script.

var events = require('events');
var myEmitter = new events.EventEmitter();

myEmitter.on('someEvent', function(msg){
console.log(msg);
});

myEmitter.emit('someEvent', 'the event is emitted');

When I run the above script, the process terminates after handling the event only once. How does Node.js know that there won't be more events that can be triggered in the future? I've seen that 'http' module's server.listen() listens for incoming connections continuously and doesn't terminate after getting the first connection. Why doesn't my code behave in the same way?

Or in other words, How can I define events that are asynchronous and listened continuously?

EDIT: I would also like to know how the events that occur unpredictably (eg. Browser button clicks, server getting a connection etc.) work under the hood, such that the program runs continuously without terminating.

Curious
  • 47
  • 6
  • In your code, you only trigger the event once? – Sami Hult Jan 08 '19 at 10:24
  • There is nothing asynchronous that would trigger the event in your script. – Bergi Jan 08 '19 at 10:27
  • 4
    Btw, `EventEmitter` is synchronous, it's just a tiny wrapper to manage subscriptions and written in plain JS. There is nothing special about it that would keep the process running - it's `server.listen()` that does this. – Bergi Jan 08 '19 at 10:28

1 Answers1

1

We are talking about two different things here. Events and Sockets.

In your case, you are saying to node that when the event named someEvent appears, you want to handle it. And then you are emitting this event. When you do, node.js sees there is a custom handler for it and calls your function. When your function ends, there are no more things to do in the program and it terminates.

Node.js does not actively wait for events like :

while (1) {
  if (isThereANewEvent()) treatTheNewEvent();
}

It's a passive wait.

On the other hand, sockets are I/O and when you are starting a server, it has an active wait. That's why your program won't terminate after calling .listen

Curious
  • 47
  • 6
Orelsanpls
  • 22,456
  • 6
  • 42
  • 69
  • Thanks. Are you saying that only the tasks that cause an 'active wait' are handled asynchronously? If so, how can I know which events cause the 'active wait'? – Curious Jan 08 '19 at 11:04
  • 3
    @Curious: Correct, only asynchronous tasks are handled asynchronously. Everything built on top to help handling asynchronous tasks are merely design patterns and these include events, promises etc. The real asynchronousness must be supplied by the OS which ultimately depends on hardware features (primarily interrupts) – slebetman Jan 08 '19 at 12:34
  • 2
    @Curious - see my answer to this question for a quick description of how asynchronous works at the low level: https://stackoverflow.com/questions/29883525/i-know-that-callback-function-runs-asynchronously-but-why/29885509#29885509 – slebetman Jan 08 '19 at 12:37