It's too late to change the name.
Also, the *new* behavior is actually how we've been describing nextTick for
quite some time even though it's never been 100% true.
On May 26, 2012, at May 26, 20125:56 PM, Tim Caswell wrote:
> I would love this, but then the name is wrong. It's more of an afterTick.
>
> On May 26, 2012 6:50 PM, "Isaac Schlueter" <i...@izs.me> wrote:
> How would you feel about changing the semantics of process.nextTick
> such that the nextTick queue is *always* cleared after every v8
> invocation, guaranteeing that a nextTick occurs before any IO can
> happen?
>
> This would imply that you can starve the event loop by doing nextTick.
> So, for example, the timeout would never fire in this code:
>
> setTimeout(function () {
> console.log('timeout')
> })
> process.nextTick(function f () {
> process.nextTick(f)
> })
>
>
> Reasoning:
>
> We have some cases in node where we use a nextTick to give the user a
> chance to add event handlers before taking some action. However,
> because we do not execute nextTick immediately (since that would
> starve the event loop) you have very rare situations where IO can
> happen in that window.
>
> Also, the steps that we go through to prevent nextTick starvation, and
> yet try to always have nextTick be as fast as possible, results in
> unnecessarily convoluted logic.
>
> This isn't going to change for v0.8, but if no one has a use-case
> where it's known to break, we can try it early in v0.9.
