[masklinn]

The platform does it: other requests are handled by other threads or processes (pooled or not), one request is going to consume 500ms and the rest will keep on trucking concurrently. Unless you've gone above the capacities of the machine itself, other requests will be little to not affected.

[christkv]

just as in node where you run multiple processes against the same socket using something like https://github.com/LearnBoost/cluster

[ricardobeat]

That's not avoiding it. The thread in question will still block for 500ms. The same holds true for a multi-process node app.

[wlievens]

The point is that in a multi-thread architecture, you can still serve requests on the other threads. In a single-process non-blocking IO architecture, blocking CPU calculations will block everyone.

Big deal. Use workers to solve that. End of story.

[etherealG]

would you mind giving an example of how you would code it so that that 1 request didn't block the rest?

in a browser I'd go with a setTimeout or setInterval hack to "fork" another thread. is this the same in node?

[timrichard]

In Node Web Development [Packt], the author uses a Fibonacci algorithm as an example that could block the event loop.

It outlines one solution where the calculation is split into callbacks dispatched through the event loop, making use of process.nextTick()