FYI: setImmediate === nextTick and identical to a setTimeout(f,0) without the clamping. -- Jorge.
On May 29, 2012, at 10:45 PM, Isaac Schlueter wrote: > Computationally expensive stuff should be done in a child process, or > a uv_work_t thread in an addon. nextTick is a bad fit for this. > setTimeout(fn, 0) is not quite as bad, but it is slower. > > We can look into adding a setImmediate function for 0.9 that matches > the semantics of the web browser. The intent of setImmediate is to be > used for cases like this, and it should be pretty easy to implement. > > On Tue, May 29, 2012 at 1:31 PM, Mikeal Rogers <mikeal.rog...@gmail.com> > wrote: >> 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. >> >>