Jorge, They're not "rare cases". Virtually every use of nextTick is specifically designed to allow the attachment of event handlers before IO occurs, and every time we use it that way, it leads to sporadic failures under load.
We're not going to change the name of the method. We're just going to make it work the way it's advertised. The only question that I can see is whether we make it simple (but allow IO starvation when it is used recursively) or keep some of the complicated logic, so that nextTicks added during nextTick are handled the same way that they are currently. Personally, I think that nextTick IO starvation is not as much of an issue as missing IO events, and making things simpler is almost always better. We can move the discussion of pros/cons here: https://github.com/joyent/node/issues/3335 On Sun, May 27, 2012 at 1:16 PM, Jorge <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 >> >
