On May 27, 2012, at 1:50 AM, Isaac Schlueter 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.
It would mean there's one more thing that can go wrong: the way it's now it's ~
impossible to block the event loop (*), the way you're proposing you could.
(*)except with long running callbacks such as fibonaccis
--
Jorge.
