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

But any putation 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 putation 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.

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

But any putation 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 putation 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.

• javascript
• node.js
• blocking
• eventemitter

• 3 Firstly, 90% of your 'Question' is not actually a question, it's more of an issue with node's Event Library, this should be brought up either as a feature request or as a possible bug on github, as for your small question I would create a question dedicated to that subject rather then squeezing it in this one. – RobertPitt Commented Apr 14, 2011 at 22:09
• 1 @RobertPitt thank you for pointing out that the question was phrased poorly. i have adjusted it. I might also mention it on github. – Raynos Commented Apr 14, 2011 at 22:14
• That's a little better, thankyou. – RobertPitt Commented Apr 14, 2011 at 22:21

2 Answers 2

JavaScript is single-threaded. That means that regardless of events, timeouts, or delaying with nextTick, any putation 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 putation 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 munication - not quite the web workers API, but close, see the URL https://github./joyent/node/blob/master/doc/api/child_process.markdown.

There's no real multi-threading in JavaScript and that's what you need to make the call non-blocking. The only thing I can think of are web-workers: https://developer.mozilla/en/Using_web_workers