On May 27, 2012, at May 27, 20121:41 PM, Isaac Schlueter wrote: > 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.
Is there, currently, a use case where recursive nextTick() would not be a bug? I know it would technically *work* at the moment, but there is a cost and I'm failing to see a valid use case for it continuing to work. I think a good error is more useful than continuing to let this code, which we all agree is a bad, persist through future releases. > > 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 <jo...@jorgechamorro.com> 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 <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 >>> >>
