I also assumed the same semantics as phidelta, and that the code would be
deferred to the *next* tick, ensuring some IO (or a another "thread" of the
same code) can get a look-in amidst my complicated processing.
What I really want is something to say "deal with this at some point, but
let any pending events go first". If nextTick isn't supposed to be for
that, can you add something that is (and is more efficient than setTimeout)
before changing the nextTick semantics to be even further from what we
require.
On Tuesday, 29 May 2012 01:43:20 UTC+1, 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.
