node.js C addon queueing by uv_queue_work

Question

I have created a C node.js addon with the help of libUV to make the addon asynchronous.

I have made several queues for this.

The code is like this, loopArray is used for storing those queues:

//... variables declarations

void AsyncWork(uv_work_t* req) {
    // ...
}

void AsyncAfter(uv_work_t* req) {
    // ...
}

Handle<Value> RunCallback(const Arguments& args) {
    // ... some preparation work

    int loopNumber = (rand() % 10);
    int status = uv_queue_work(loopArray[loopNumber], &baton->request, AsyncWork, AsyncAfter);
    uv_run(loopArray[loopNumber]);
    return Undefined();

}


extern "C" {
    static void Init(Handle<Object> target) {
        int i = 0;
        for (i = 0; i< 10; i++){
            loopArray[i] = uv_loop_new();
        }           

        target->Set(String::NewSymbol("callback"), FunctionTemplate::New(RunCallback)->GetFunction());
    }
}

NODE_MODULE(addon, Init)

The problem is that, even I created 10 queues for the CPU-demanding tasks. node.js does not switch between tasks while processing one of the queue. Is it due to the single-thread nature of node.js?

Is so, does uv_thread_create helps the situtation?

I cannot find any code sample for this, so I am not sure how to use it.

Thanks!

score 4 · Accepted Answer · answered Jun 27 '12 at 16:28

That is the main idea behind node's architecture: Using function call(back)s and a main event loop to run them instead of using threads to process multiple jobs in parallel.

If what you want to do is to process a queue of jobs, the best way to do it is doing one job at a time. Utilizing multiple cpu cores on a system is done by multiple node instances instead of threads. We have child_process and cluster node modules for this.

When you create multiple threads, let's say you want to run 10 threads for your work, if your system has 8 cpu cores, you are killing the performance by giving unnecessary work to operating system's scheduler. This is a very important point you should take into account. If you have 8 cores, you should not create more than 8 threads in parallel if you want the maximum performance.

For node, we don't try to create multiple queues or threads in one process. Instead, we employ multiple node processes, again maximum one process per core.

If you are going to process a queue which is already there. In this kind of work, you do not need your C module to be asynchronous.

We want asynchronous behavior when we have jobs coming from outside like http requests on a web server. On a web server, our job comes in a way that we cannot control. People and other machines connect to our server whenever they want and we want to answer each of them as quickly as possible. For this, we do not want any request to block others. We need to handle as many requests as we can in parallel.

If you are running on rows of a database table or making some calculations over a long list of parameters however, you are in a very different kind of business. You have your job queue in front of you waiting for your way of management. Your jobs are not coming to your system in a way you have no control over. In this kind of business, to reach the ultimate efficiency and hit the topmost profits, you should run jobs one after another without any switching between them. Parallelism is only good when you have multiple cores and to employ them, the best practice for node is to use multiple node processes.

I have doubt. As I am not creating threads, but creating queues. Isn't that the node will switch over different queues at a random time? — Harold Chan, Jun 29 '12 at 04:22
Node behaves much differently than an OS Scheduler does. It never stops a call in the middle and switches to another. It is our responsibility to finish our functions without taking too much of the shared time. On JS, we have facilities provided by node like process.nextTick. On C/C++ modules you write for Node, you have two threads, one for interaction with Node, one for your async work. Even though you are using threads here, it is very different than using them to utilize cpu cores or to reply multiple requests. Node internally uses a few threads for signal/interprocess comm. etc, too. — hasanyasin, Jun 29 '12 at 05:02
For a longer+clearer explanation, see also http://stackoverflow.com/a/11278689/1191620 — hasanyasin, Jul 02 '12 at 18:09

node.js C addon queueing by uv_queue_work

1 Answers1