Ok, if we don't want to change API, I'm fine with keeping it called nextTick. In a way it is the "next tick" before any scheduled real events, but after any already schedules nextTicks. Technically all ticks are all part of the same root stack, there is a blocking uv.run() call they all originate from. So the nextTick processor that executes when a tick returns would be like a new tick even though it's the same event source.
Let's keep the existing API and definition and match the implementation to do what we've been saying for years (the proposed change). Simple and direct. It will break some code, but that's ok I think. On Sun, May 27, 2012 at 10:51 AM, Isaac Schlueter <i...@izs.me> wrote: > Another option, which may prevent recursive starvation, would be to > process all the nextTicks at the end of the current tick, but any > additional nextTicks added in that pass would wait a bit. > > On Sun, May 27, 2012 at 1:43 AM, Jorge <jo...@jorgechamorro.com> wrote: > > And the proper name IMO would be *this*Tick not *next*Tick :-P > > It's too late to change it, and adding additional API would be worse. > The way people think it works is "run this function immediately after > the current code has run to completion," which is what it would do. > > > And perhaps it should be internal, not part of the public API: > _thisTick(). But that depends: exactly *where* have you seen the problem > you mention, @izs? > > lib/http.js >
