doc/api/process.markdown

@@ -457,7 +457,7 @@ This will generate:
 On the next loop around the event loop call this callback.
 This is *not* a simple alias to `setTimeout(fn, 0)`, it's much more
 efficient.  It typically runs before any other I/O events fire, but there
-are some exceptions.  See `process.maxTickDepth` below.
+are some exceptions.
 
     process.nextTick(function() {
       console.log('nextTick callback');
@@ -513,29 +513,6 @@ This approach is much better:
       fs.stat('file', cb);
     }
 
-## process.maxTickDepth
-
-* {Number} Default = 1000
-
-Callbacks passed to `process.nextTick` will *usually* be called at the
-end of the current flow of execution, and are thus approximately as fast
-as calling a function synchronously.  Left unchecked, this would starve
-the event loop, preventing any I/O from occurring.
-
-Consider this code:
-
-    process.nextTick(function foo() {
-      process.nextTick(foo);
-    });
-
-In order to avoid the situation where Node is blocked by an infinite
-loop of recursive series of nextTick calls, it defers to allow some I/O
-to be done every so often.
-
-The `process.maxTickDepth` value is the maximum depth of
-nextTick-calling nextTick-callbacks that will be evaluated before
-allowing other forms of I/O to occur.
-
 ## process.umask([mask])
 
 Sets or reads the process's file mode creation mask. Child processes inherit

doc/api/timers.markdown

@@ -55,11 +55,10 @@ callbacks and before `setTimeout` and `setInterval` . Returns an
 can also pass arguments to the callback.
 
 Immediates are queued in the order created, and are popped off the queue once
-per loop iteration. This is different from `process.nextTick` which will
-execute `process.maxTickDepth` queued callbacks per iteration. `setImmediate`
-will yield to the event loop after firing a queued callback to make sure I/O is
-not being starved. While order is preserved for execution, other I/O events may
-fire between any two scheduled immediate callbacks.
+per loop iteration. `setImmediate` will yield to the event loop after firing a
+queued callback to make sure I/O is not being starved. While order is preserved
+for execution, other I/O events may fire between any two scheduled immediate
+callbacks.
 
 ## clearImmediate(immediateId)