I think that the current semantics have value. I use nextTick when I want to ensure that io can happen between the invocation and the ticked call. As well as to work with a new call stack.
For example when I emit an event whose lister also emits an event and so on, I create a potentially long chain of stuff that can happen within a tick. So when I emit from within a listener I usually nextTick the emit to allow io in between. So if you change nextTick to really mean "at the end of this tick", at least we will want a function like reallyNextTick that keeps the current behavior. Of course I would need to do a search replace over a lot of code, but I could live with that. On May 26, 7:50 pm, 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.
