I have never seen nextTick recommended for breaking up computationally
expensive tasks, this is what cluster and child_process are for.
Also, setTimeout(cb,0) is very efficient in node and does not suffer the
penalties we are familiar with from the browser. It's actually a better fit for
this use case than nextTick().
-Mikeal
On May 29, 2012, at May 29, 201212:23 PM, Bruno Jouhier wrote:
> +1
>
> nextTick is the efficient way to yield to another "thread of processing"
> (thread between quotes of course) when performing an expensive computation.
> So it is the antidote to starvation and thus a very useful call.
>
> If you change its behavior, you should at least provide a replacement call
> which will be at least as efficient (unlike setTimeout(cb, 0)). And then why
> not keep nextTick as is and introduce another call with a different name
> (like afterTick as someone suggested) if you really need one.
>
>
> On Tuesday, May 29, 2012 2:43:20 AM UTC+2, phidelta wrote:
> 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 <i...@izs.me> 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.
