Question

I can write non-blocking I/O in Node.js very easily. It’s what the entire library is set up for.

But any computation done is blocking. Any message passing over event emitters are blocking.

For example, emitting events are resolved immediately and are thus blocking:

var e = new process.EventEmitter;
e.on("foo", function() {
    console.log("event");
});
process.nextTick(function() {
    console.log("next tick");
});
setTimeout(function() {
    console.log("timeout");
}, 0);
e.emit("foo");

> event
> next tick
> timeout

Apart from wrapping calls in nextTick, how do I make code non-blocking?

I want to do as little computation per cycle of the event loop as possible, so that I can serve as many clients simultaneously as possible.

How do I write my code in a non-blocking fashion?

And when I have non-blocking code, how do I scale that across multiple processes?

One option is waiting for the WebWorker sub-process API to be finished.

Answer 1

JavaScript is single-threaded. That means that regardless of events, timeouts, or delaying with nextTick, any computation done will block the whole process.

If you split your processing in steps using process.nextTick, like it’s done with setTimeout(fn, 0) on the client-side to avoid blocking the UI, you could spread your workload over a longer time span, giving some room for other functions to run.

But that’s a very innefective solution – the total amount of work is the same, distributed among all cycles (making each request a little slower). In practice, any kind of computation that is expected to take more than a few milliseconds should be offloaded to a different process. To maximize concurrency you should always return to the event loop as quickly as possible.

child_process.fork() was added to v0.5 a few days ago. It simplifies child process creation and communication – not quite the web workers API, but close, see the URL
https://github.com/joyent/node/blob/master/doc/api/child_process.markdown.