In 3.2-pre (git master upstream) Callbacks pushed to process.nextTick are delayed few seconds in situation where the program has nothing to do.
Examination with gdb shows that the program spends the extra delay
inside the libev event loop polling and my theory is that the event
loop goes into the event poll to wait for new async events to come,
but doesn't check before if it has something to execute in the
process.nextTick() queue. In practive I've observed polling times from
0.7 second to almost four seconds.
The process.nextTick() queue is emptied after the poll has ended, so this
problem might not appear in practice in production environments where
the process is getting constant stream of new events.
Example GDB stacktrace on linux.
(gdb) where
#0 0x00002aaaac50c018 in epoll_wait () from /lib64/libc.so.6
#1 0x000000000050a2eb in epoll_poll ()
#2 0x000000000050b96a in ev_run ()
#3 0x00000000004df207 in node::Start ()
#4 0x00002aaaac455994 in __libc_start_main () from /lib64/libc.so.6
#5 0x00000000004dc409 in _start ()
(gdb) quit
Example GDB stacktrace on mac.
0x00007fff8851516a in kevent ()
(gdb) where
#0 0x00007fff8851516a in kevent ()
#1 0x000000010005a065 in kqueue_poll (timeout=3.5926599502563477) at
ev_kqueue.c:101
#2 0x000000010005c4c9 in ev_run (flags=0) at ../deps/libev/ev.c:2414
#3 0x0000000100011bc3 in ev_loop (flags=0) at ev.h:782
#4 0x0000000100016a9f in node::Start (argc=2, argv=0x7fff5fbff9c8)
at ../src/node.cc:2008
#5 0x000000010001127f in main (argc=2, argv=0x7fff5fbff9c8) at ../src/
node_main.cc:6
Jorge provided a good example code which shows the bug:
setTimeout(function () {
t= Date.now()-t;
STOP= 1;
console.log(["ctr: ",ctr, ", t:", t, "ms -> ", (ctr/t).toFixed(2), "KHz"].join(''));
}, 2e3);
var ctr= 0;
var STOP= 0;
var t= Date.now()+ 2;
while (t > Date.now()) ; //get in sync with clock
(function foo () {
if (STOP) return;
process.nextTick(foo);
ctr++;
})();
Running this on node 0.2.5 works just fine:
[root@ ~]# node-v0.2.5/build/default/node testbug.js
ctr: 1124162, t:1998ms -> 562.64KHz
But running this on node 3.2-pre (latests from git upstream) shows the complete stall of the execution.
[root@ ~]# node testbug.js
ctr: 8, t:1999ms -> 0.00KHz
Relevat google groups thread: http://groups.google.com/group/nodejs/browse_thread/thread/cac74a76a6c7e298
In 3.2-pre (git master upstream) Callbacks pushed to process.nextTick are delayed few seconds in situation where the program has nothing to do.
Examination with gdb shows that the program spends the extra delay
inside the libev event loop polling and my theory is that the event
loop goes into the event poll to wait for new async events to come,
but doesn't check before if it has something to execute in the
process.nextTick() queue. In practive I've observed polling times from
0.7 second to almost four seconds.
The process.nextTick() queue is emptied after the poll has ended, so this
problem might not appear in practice in production environments where
the process is getting constant stream of new events.
Example GDB stacktrace on linux.
Example GDB stacktrace on mac.
Jorge provided a good example code which shows the bug:
Running this on node 0.2.5 works just fine:
But running this on node 3.2-pre (latests from git upstream) shows the complete stall of the execution.
Relevat google groups thread: http://groups.google.com/group/nodejs/browse_thread/thread/cac74a76a6c7e298