On Wed, May 30, 2012 at 4:13 PM, phidelta <philipp.dun...@gmail.com> wrote:
> > Conceptually the event loop works something like a task-list on paper > (Or that is how I visualize it). > > What happens is that there is a pad of paper on a desk. Whenever an > event happens, such as IO, or node Startup, that's like writing a task > onto the pad. > Then the event loop thread comes along and rips of the top sheet and > then merrily goes about executing the tasks that are on that sheet. In > the mean time new event get written onto the top sheet of the pad > remaining on the table. And of course when a task in the hand of the > event-loop wants to write something onto the pad on the table to be > run the next time around, it simply calls nextTick. > > That is how the current nextTick semantics are and were defined. > Except that's not nextTick really works. This is the problem. Very few people understand how exactly nextTick works and it's not ideal for any use case. This is exactly how the proposed setImmediate would work though. :) > > Now there is a need to have something that rather than writing on the > pad on the table, writes on the piece of paper the event-loop holds. > To me that function cannot be named nextTick. Maybe call it > process.thisTick, because that is what it is doing. > > I proposed calling it afterTick, but if Isaac doesn't want to rename it, I'm not dead set on it. nextTick is correct enough that I'll live with it. Now imagine a situation where an event listener also > emits events. This is synchronous, so it is now possible to starve the > loop, by creating a chain reaction. Ok, so assuming you've accidentally written an infinite recursive loop using events. The current semantics of nextTick are not going to save you from this. They will allow some I/O and timer events to seep in and not completely block your process, but it's still going to busy-loop forever. This will burn a lot of CPU needlessly and will probably affect performance of the server. The solution is to change the event logic in your app to not deadlock itself in the first place (btw the ember.js code has some great techniques for dealing with this). If nextTick blocked the event loop, this would be more obvious and people would never make this mistake in the first place because they would be forced to do it right.
