用setTimeout在Node.js中同步循环-奇怪的，显然是故意的行为

Question

I was investigating a poorly-behaving piece of Node.js code we've got running in production, and I saw this odd little paradigm to intentionally create an infinite loop. I hope it's an anti-pattern, but either way while I was playing around with it I found some strange behavior.

The basic idea is that we have an outer function that does some work that takes indeterminately long and then calls its callback, and an inner function that also does some indeterminate work (that involves a database connection), but only after calling setTimeout(function() {outer(inner)}, someDelay) . So, ideally, both functions finish within 15 seconds, go to sleep, and then wake back up to re-sync the environment, but of course that's not always what happens.

It seems obvious for a few reasons that this is a bad design, but regardless, I found the following toy example's behavior really surprising.

'use strict';

var outer = function(callback) {
    setTimeout(doWork, 1000);

    function doWork() {
        console.log('Did outer work.');
        callback();
    }
}

var inner = function() {
    setTimeout(function() {outer(inner)}, 2000);
    process.stdin.resume();
    process.stdin.once('data', function(data) {
        console.log('Got ' + data);
        process.stdin.pause();
        console.log('Did inner work.');
    });
}

outer(inner);

When we run this, the outer function "does its work" every second, resulting in an additional outer(inner) call added to the stack every 2 seconds (I figure). Each of the calls to inner() , though, blocks on waiting for stdin (the idea was to simulate a database lock). If I wait until outer() is called 5 times before sending anything to stdin , that same data is processed by all 5 instances of inner() on the stack.

I was really surprised by that - I guess I expected just one function call to accept that first input stdin and the other four to block. Again, this is a bad design, but - the question: Is this desirable? Did someone intentionally make setTimeout() and the JS callstack to behave in this way, or is it a side-effect of some other language feature?

Or does this make sense, and I'm just thinking about it the wrong way?

Thanks in advance, and I'm sorry that it's kind of a vague one.

Answer 1

I hope it's an anti-pattern

No, there's nothing wrong with it. Most server-like applications are coded using an infinite loop - you want them to handle connections forever (that is, until you kill it or it crashes).

resulting in an additional outer(inner) call added to the stack every 2 seconds (I figure).

No. setTimeout is asynchronous, which means it returns immediately, the rest of the code runs to completion, and then the scheduled callback is executed on a fresh new call stack. The stack does not grow in this semi-recursive pattern.

Each of the calls to inner(), though, blocks on waiting for stdin (the idea was to simulate a database lock).

No, once() does not block. It just installs a handler that will be executed once when the event occurs the next time.

I was really surprised by that if I wait until outer() is called 5 times before sending anything to stdin, that same data is processed by all 5 instances of inner() on the stack.

Yes - there's 5 data event handlers waiting for the event, and they all get executed with the input when the event is fired.

If you wanted to block until the event occurs before continuing the recursion, you would need to put the setTimeout that schedules the next read inside the data event listener:

function inner() {
    process.stdin.resume();
    process.stdin.once('data', function(data) {
        console.log('Got ' + data);
        process.stdin.pause();
        console.log('Did inner work.');
        setTimeout(function() {outer(inner)}, 2000);
    });
}

You might even want to omit the timeout here and call outer(inner); directly.

Answer 2

The behavior isn't surprising: You're hooking up multiple separate handlers to the stdin data event, so when the event runs, it calls each of those handlers. It's exactly like this:

process.stdin.once('data', function(data) {
    console.log("callback1: " + data);
});
process.stdin.once('data', function(data) {
    console.log("callback2: " + data);
});
process.stdin.once('data', function(data) {
    console.log("callback3: " + data);
});

If you run that, then type something and press Enter, all three callbacks receive the event, because after all, all three callbacks are registered for the event.

That's exactly what inner is doing: Hooking the data event for multiple callbacks.

---

This version, showing the number of handlers hooked to the data event (and when things are actually queued), may make things a bit clearer:

'use strict';

var handlerCounter = 0;

var outer = function(callback) {
    console.log("outer called, queue doWork for 1s from now");
    setTimeout(doWork, 1000);

    function doWork() {
        console.log('doWork called');
        callback();
    }
}

var inner = function() {
    console.log('Queueing outer(inner) call for 2s from now');
    setTimeout(outer, 2000, inner);
    process.stdin.resume();
    ++handlerCounter;
    console.log('Adding another handler to the `data` event, total will be: ' + handlerCounter);
    process.stdin.once('data', function(data) {
        --handlerCounter; // Since `once` removed it
        console.log('Got ' + data + ', handlers now: ' + handlerCounter);
        process.stdin.pause();
    });
}

outer(inner);