Question

Have been following this fabulous tutorial. Being new to Javascript and functional programming, I wanted to understand what non-blocking essentially means. I intentionally added a “sleep” of 10 seconds in my JS code, to achieve blocking behavior.

    function route(pathname, handle)
{
    console.log("About to route a request for :"+pathname);

    if(typeof handle[pathname]==='function')
    {
        handle[pathname]();
    }
    else
    {
        console.log("No request handler for "+pathname);
    }


    sleep(10000);
    console.log("Exiting router");
}

function sleep(milliSeconds)
{
    var startTime = new Date().getTime(); // get the current time
    while (new Date().getTime() < startTime + milliSeconds); // hog cpu
}

exports.route=route;

This code is being used as a callback from another “server” script, which I am calling from a browser. I expected that once I fire simultaneous 100 requests to my server script, I would get parallel 100 responses after 10 seconds. But this code runs through the request one by one. This certainly fails the philosophy behind node.js right ?? This doesn’t even happen when I do such bad code in a Java servlet and run on Tomcat !

Another observation in this scenario, was that the requests were not handled chronologically – they are executed randomly. This doesn’t sound good to me !!

I believe there is some issue with my code – please help me understand the concepts here, with the answers to my 2 queries (the other one on chronology).

Thanks !

Answer 1

I expected that once I fire simultaneous 100 requests to my server script, I would get parallel 100 responses after 10 seconds. But this code runs through the request one by one.

Yes. Node is strictly single-threaded so each request will be run in serial. There is no parallelism in the JavaScript code (although the underlying I/O subsystem of the computer may be doing things in parallel).

This certainly fails the philosophy behind node.js right??

No. The philosophy of node.js is to execute your event handlers as quickly as possible once I/O events are ready for action.

Note that your “sleep” function doesn’t really sleep, instead it pegs the CPU – since node is single-threaded all other actions will block on the CPU crunching code – the same would happen if your code was doing some actual CPU intensive actions. However, if your code was instead performing I/O operations (and it was designed properly), then node will schedule other actions around your I/O blocking code. Think of it this way – node.js prevents code from blocking on I/O, not from blocking on CPU usage. If your code is CPU intensive and you’re worried about it blocking other handlers then you must design it in a way to yield to the event loop to let other handlers run.

Another observation in this scenario, was that the requests were not handled chronologically – they are executed randomly.

Yes, this is possible. You must remember that node.js is essentially just a way to attach “event handlers” to I/O events of interest. These I/O events are triggered by actions in the underlying operating system (e.g. a socket connection has been established, a file read has completed, etc.) and node.js calls your handlers in response.

Since the operating system does its own “internal bookkeeping” about when things actually happen and when it thinks they are available for “user space” processes, there may be a difference between when you expect them to happen and when the computer says they actually happen. Moreover, I don’t think that node (or perhaps even the OS) guarantee “fairness” when scheduling events.