I don't think it's fair to say that a recursive nextTick is a bug, any more than it is to say a recursive function is a bug.
We can add some kind of guard on it so that it'll throw a RangeError if you recurse 10,000 times or something. On Sun, May 27, 2012 at 1:49 PM, Mikeal Rogers <[email protected]> wrote: > > 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 <[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 >>>> >>> >
