The more I think about this the more I want to scream DONT TOUCH MY NEXT TICK.
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. 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. So I hope you understand why I am opposed to changing nextTick to thisTick. <rant> BTW I was not proposing it to cut up processor intensive tasks, but rather to prevent event-loop starvation. Remember Emitter.emit is synchronous. 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. I usually use nextTick to emit events from an event listener for that reason. And no setTimeout is semantically not the right thing, because all I want is that the event- loop execute 1 tick and setTimeout(task, 0) is defined ans anywhere between 0 and 4 ms. Now I realize that node may be more fine grained here, but the semantics of the definition do make a difference </rant> On May 27, 1:50 am, Isaac Schlueter <[email protected]> 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.
