There are already many ways to starve/block the event loop.
You could have an infinite loop
while (true) {}
Or a recursive loop that blocks till the stack overflows
function a() {
a();
}
a();
Now these new semantics would add another way to do the recursive loop,
except this time the trampoline is built in and the stack doesn't overflow.
function a() {
process.nextTick(a);
}
a();
If we're worried about changing the name to match the meaning and we're
worried about breaking existing code (I know I have some that accidentally
depends on the non-blocking nature), we could add a new function
process.afterTick that does the new semantics and deprecate process.nextTick
.
Then no code breaks and we eventually get the right behavior with the right
name.
On Sat, May 26, 2012 at 10:40 PM, Mikeal Rogers <mikeal.rog...@gmail.com>wrote:
>
>
> On May 26, 2012, at May 26, 20128:16 PM, Jorge wrote:
>
>
> 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.
>
>
> That's one way to look at it.
>
> Another way would be to say that there is already something that can go
> wrong when people make the assumption that no IO will fire before their
> nextTick() hander, which is an assumption most people make although I doubt
> there are many cases where the assumption not being true will break
> something.
>
> This gives us a true assumption, which is a feature. In my opinion, it's a
> better feature than this edge case where you block the event loop (although
> I think we should put in a guard for it so that we can throw a nice
> exception).
>
> -Mikeal
>
