I would leave .nextTick() as is and add a .thisTick() for the rare cases that @izs wants to fix.
On May 27, 2012, at 8:26 PM, Tim Caswell wrote: > 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 >
