On Fri, Jun 1, 2012 at 2:54 PM, Marco Rogers <[email protected]> wrote: > nextTick works perfectly well for > large n. It doesn't work well when it is used to defer execution outside the > current stack, AND n is large, AND you still want to catch pending data > events.
Not working for "defer execution outside the current stack and still run before any data events" is exactly what I mean by "not working". That's what nextTick is for. > Even though it was designed for that, it ended up being not the > right solution for that. Aka, "it doesn't work for what it was designed for". > We're asking for another solution that works > for deferring and catching data events for large n. But don't change > nextTick to do so. Why not? What actual code will break? If we can change nextTick so that it works as intended, but also works for every actual program that would be adversely affected (not every hypothetical program we can imagine), then would that be ok? Or are you just opposing changes on principle? > I still don't think this is an unreasonable request. You > can decide not to take the advice, but what you're doing is trying > to re-characterize this request to something that it is not. It's not just "deciding to not take the advice". Show me a real world use case where you need the current nextTick semantics. Like, a production application that will be broken by this change. I'm aware of several production applications that are suffering without the proposed change, and there are many ways that we can make things fine for the problems presented in this thread. > As for what code needs to change. I think it makes more sense for request, > filed and whatever other popular libraries to update with a new method, then > for all the people writing successful applications using nextTick directly to > have to change the way they understand it and potentially change every place > it's used in their app. The problem is that those "successful applications" are very likely going to be bitten by this issue eventually. If they currently assume that nextTick will defer until after pending IO, then they'll see exactly the same behavior 99.9% of the time. The other 0.1%, it'll be as if the IO was a ms slower. It's *only* relevant if nextTicks are being added recursively, and even then, I think we can work around it. > Consider a server that's handling requests. For simplicity, it has 2 types. A > where no i/o happens but there are some defers to the EL using nextTick. And > B where some i/o can happens... In reality, *any* IO will be slow enough, and nextTick fast enough, that the case presented won't matter. I've seen the flamegraphs of node servers in production. Time spent in JavaScript is almost always tiny, unless something is very deeply wrong (infinite loop, etc.) It's all IO and GC, especially when under load. This is all blown way out of proportion. We have a real bug now that will require some careful thought to fix. You've all given some very helpful feedback, but "don't fix the bug or the world will die" isn't super helpful, so I'm not really taking those bits to heart too much. We're going to fix it in 0.9. Then, once it's done, we can see what it breaks in the unstable branch, and put in the necessary affordances for those things, if they in fact exist, before it becomes stable. If it's actually not possible to make it all work, then we'll figure something else out. Chill. It's gonna be ok.
