So reading the proposed spec for setImmediate[1], it says: This specification defines an interface for web applications to flush the > browser event queue and receive an immediate callback.
And from the Mozilla docs[2] on it, the purpose is: > This method is used to break-up long running operations and run a callback > function immediately after the browser has completed other operations such > as events and display updates. The one thing I don't understand from this spec is what happens if new events get queued while flushing the event queue, but after the user called setImmediate. Will they go behind the setImmediate callback or before it. If they go before it, there is the possibility to starve the setImmediate functions where they never get a chance to run. event queue = timer, io1, io2, setImmediate the callback for io2 takes 3ms and during that time io3 comes in. What should happen next? [1]: https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/setImmediate/Overview.html [2]: https://developer.mozilla.org/en/DOM/window.setImmediate On Tue, May 29, 2012 at 3:45 PM, Isaac Schlueter <i...@izs.me> 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. > > > > >
