Signals

In many ways, evented programming is like hardware interrupt programming. Interrupts do exactly what their name suggests. They use their ability to interrupt whatever a controller or the CPU or any other device is doing, demanding that their particular need be serviced immediately.

In fact, the Node process object exposes standard Portable Operating System Interface (POSIX) signal names, such that a node process can subscribe to these system events.

This is a very elegant and natural way to expose a Node process to operating system (OS) signal events. One might configure listeners to catch signals instructing a Node process to restart or update some configuration files or simply clean up and shut down.

For example, the SIGINT signal is sent to a process when its controlling terminal detects a Ctrl-C (or equivalent) keystroke. This signal tells a process that an interrupt has been requested. If a Node process has bound a callback to this event, that function might log the request prior to terminating, do some other cleanup work, or even ignore the request:

setInterval(function() {}, 1e6);
process.on('SIGINT', function() {
    console.log('SIGINT signal received');
    process.exit(1);
})

Here we have set up a far future interval such that the process does not immediately terminate, and a SIGINT listener. When a user sends a Ctrl-C interrupt to the terminal controlling this process, the message SIGINT signal received will be written on the terminal and the process will terminate.

Now consider a situation in which a Node process is doing some ongoing work, such as parsing logs. It might be useful to be able to send that process a signal, such as update your configuration files or restart the scan. You may want to send such signals from the command line. You might prefer to have another process do so—a practice known as Inter-Process Communication (IPC).

Create a file named ipc.js containing the following code:

setInterval(function() {}, 1e6);
process.on('SIGUSR1', function() {
    console.log('Got a signal!');
});

SIGUSR1 (and SIGUSR2) are user-defined signals (they are triggered by no specific action). This makes them ideal signals for custom functionality.

To send a command to a process you must determine its process ID (PID). With a PID in hand, processes can be addressed, and therefore communicated with. If the PID assigned to ipc.js after being run through Node is 123, then we can send that process a SIGUSR1 signal using the following command line:

kill –s SIGUSR1 123

ps aux | grep ipc.js

Forks

A fundamental part of Node's design is to create or fork processes when parallelizing execution or scaling a system—as opposed to creating a thread pool, for instance. We will be using child processes in various ways throughout this book, and learn how to create and use them. Here the focus will be on understanding how communication events between child processes are to be handled.

To create a child process one need simply call the fork method of the child_process module, passing it the name of a program file to execute within the new process:

var cp = require('child_process');
var child = cp.fork(__dirname + '/lovechild.js');

In this way any number of subprocesses can be kept running. Additionally, on multicore machines, forked processes will be distributed (by the OS) to different cores. Spreading node processes across cores (even other machines) and managing IPC is (one) way to scale a Node application in a stable, understandable, and predictable way.

Extending the preceding, we can now have the forking process (parent) send, and listen for, messages from the forked process (child):

child.on('message', function(msg) {
    console.log('Child said: ', msg);
});
child.send("I love you");

Similarly, the child process (its program is defined in lovechild.js) can send and listen for messages:

// lovechild.js
process.on('message', function(msg) {
    console.log('Parent said: ', msg);
    process.send("I love you too");
});

Running parent.js should fork a child process and send that child a message. The child should respond in kind:

Parent said:  I love you
Child said:  I love you too

Another very powerful idea is to pass a network server an object to a child. This technique allows multiple processes, including the parent, to share the responsibility for servicing connection requests, spreading load across cores.

For example, the following program will start a network server, fork a child process, and pass this child the server reference:

var child = require('child_process').fork('./child.js');
var server = require('net').createServer();
server.on('connection', function(socket) {
    socket.end('Parent handled connection');
});
server.listen(8080, function() {
    child.send("The parent message", server);
});

In addition to passing a message to a child process as the first argument to send, the preceding code also sends the server handle to itself as a second argument. Our child server can now help out with the family's service business:

//    child.js
process.on('message', function(msg, server) {
    console.log(msg);
    server.on('connection', function(socket) {
        socket.end('Child handled connection');
    });
});

This child process should print out the sent message to your console, and begin listening for connections, sharing the sent server handle. Repeatedly connecting to this server at localhost:8080 will result in either Child handled connection or Parent handled connection being displayed; two separate processes are balancing the server load. It should be clear that this technique, when combined with the simple inter-process messaging protocol discussed previously, demonstrates how Ryan Dahl's creation succeeds in providing an easy way to build scalable network programs.

File events

Most applications make some use of the filesystem, in particular those that function as web services. As well, a professional application will likely log information about usage, cache pre-rendered data views, or make other regular changes to files and directory structures.

Node allows developers to register for notifications on file events through the fs.watch method. The watch method will broadcast changed events on both files and directories.

watch accepts three arguments, in order:

This example will set up a watcher on itself, change its own filename, and exit:

var fs = require('fs');

fs.watch(__filename, { persistent: false }, function(event, filename) {
    console.log(event);
    console.log(filename);
})

setImmediate(function() {
    fs.rename(__filename, __filename + '.new', function() {});
});

Two lines, rename and the name of the original file, should have been printed to the console.

Watcher channels can be closed at any time using the following code snippet:

var w = fs.watch('file', function(){})
w.close();

It should be noted that fs.watch depends a great deal on how the host OS handles file events, and according to the Node documentation:

The author has had very good experiences with the module across many different systems, noting only that the filename argument is null in callbacks on OS X implementations. Nevertheless, be sure to run tests on your specific architecture—trust, but verify.

Deferred execution

One occasionally needs to defer the execution of a function. Traditional JavaScript uses timers for this purpose, the well-known setTimeout and setInterval functions. Node introduces another perspective on defers, primarily as means of controlling the order in which a callback executes in relation to I/O events, as well as timer events properly.

We'll learn more about this ordering in the event loop discussion that follows. For now we will examine two types of deferred event sources that give a developer the ability to schedule callback executions to occur either before, or after, the processing of queued I/O events.

var events = require('events');

function getEmitter() {
    var emitter = new events.EventEmitter();
    emitter.emit('start');
    return emitter;
}

var myEmitter = getEmitter();

myEmitter.on("start", function() {
    console.log("Started");
});

var events = require('events');

function getEmitter() {
    var emitter = new events.EventEmitter();
    process.nextTick(function() {
        emitter.emit('start');
    });
    return emitter;
}
var myEmitter = getEmitter();
myEmitter.on('start', function() {
    console.log('Started');
})