so I guess in a way setImmediate(fn) could be described fairly accurately as a faster setTimeout(fn, 0). As I understand timer events get put at the end of the queue as well.
On Tue, May 29, 2012 at 5:53 PM, Tim Caswell <[email protected]> wrote: > > > On Tue, May 29, 2012 at 5:22 PM, Jorge <[email protected]> wrote: > >> FYI: setImmediate === nextTick and identical to a setTimeout(f,0) without >> the clamping. >> >> > Not at all. > > In the current libuv event loop there are 4 parts to a cycle (libuv guys > correct me if I get this wrong) > > nextTickGeneration - nextTickGeneration - TimerEvents - IOEvents > > So if I register a nextTick in a timer callback, the I/O events will get > executed first. If I execute one in an I/O event, it's generation will > happen next. If I set another nextTick in that first generation, it will > get executed right away, but if I set yet another in that second > generation, it will get delayed till after both timers and I/O events. > > I can't think of a single use case this is ideal for. It's a hack and a > compromise. We can do better by having two APIs that do what they intend > to do. > > The proposal for nextTick would look like > > AnyTimerOrIOEvent - flushAllNextTicks > > Thus any nextTick I schedule will get run before the next real event. > This includes all nextTicks registered from other nextTicks. > > setTimeout simply starts a timer and when it expires it gets put in the > event queue as a timer event. > > setImmediate would put the function in the queue with the rest of the real > events, but at the end. > > nextTick != setTimeout 0 != setImmediate > > >> 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 <[email protected]> >> 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 <[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. >> >> >> >> >> >> >
