On May 27, 2012, at 10:49 PM, Mikeal Rogers 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.
Is there a simple test that demonstrates the problem somewhere? >> 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. "the way it's advertised" it's a *next*Tick. If you make it run on the same tick it's no longer a nextTick. Unless you want to discuss too what constitutes a tick? > Is there, currently, a use case where recursive nextTick() would not be a bug? I would not call it a bug. But the point is not whether a recursive nextTick is a bug or not, the point is whether a *next*Tick()ed function should run on the *current* tick, or on the *next* tick. Because if node doesn't even look at and dispatch any pending events between a tick and the next, then we're in the same tick not in the next. > 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. The sky is going to fall on our heads the day nextTick() blocks node :-P > I think a good error is more useful than continuing to let this code, which > we all agree is a bad, I don't agree it's bad. And where's the problem @izs says: in user code or in node's internal code? If it's in the latter there's no need to touch nextTick. > <snip> -- Jorge.
