Okay, let's try to get back on track. Let me apologize for my part in taking things in an unproductive direction.
> Not true. You're talking about adding a single handler, not recursively > adding handlers forever, and I'm not seeing a case where you could ever do > so many of these legitimately that aren't on their own CPU intensive that > you would starve IO. > > From what I can tell this use case will work better and won't starve IO > unless you have a bug where you're recursively adding handlers forever. > > If you do add so many handlers recursively that you starve IO then you'll > hit the guard I already proposed, so it will fail. > Okay this is a relevant point I think. In my mind, "Starving i/o" doesn't just mean your program locks up forever. As I said, it's more about your throughput profile changing. Essentially right now when you call nextTick, you should be aware that you are yielding completely to the event loop. Anything can happen between now and the time your callback is fired. Same as setTimeout(fn, 0), except given slightly higher priority and without the overhead of unnecessary delay checking. This goes back to the idea of priority. The proposed change ups the priority of of nextTick callbacks. What this means is that every operation that doesn't do i/o is potentially higher priority than those that do i/o. Instead of continuing to argue. Let me ask some questions to make sure I'm still interpreting things properly. 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. Currently there's this scenario with requests coming in A1 start A2 start B1 start A1 callback // after defer A2 callback // after defer A3 start A4 start B1 callback // after i/o A3 callback // after defer A4 callback // after defer Reasonably interleaved. But with the proposed change to nextTick, any A requests that come in before the B callback, will get priority over the B callback. A1 start A2 start B1 start A1 callback // after defer A2 callback // after defer A3 start A4 start A3 callback // after defer A4 callback // after defer B1 callback // after i/o The B callback is pushed to the end because nextTicks take priority. As load increases, callbacks for B type requests get pushed further out and their time profiles change from what they currently are in as system like this. Am I misunderstanding this? I could be. But even so, I think it's not good if this change expects most developers to start worrying about the priority of their callbacks. > > You make it sound like we called all these developers names, we didn't. We > said "that's not what this is for, that's what this other thing is for." A > perfectly valid point for a technical argument. The only time I got upset > was about the benchmark which tested something that wasn't even a real use > case. > Bruno always makes you upset. You guys should hug it out. > > Here is why your proposed solution, of provided a new API for people who > have enough load to step on this, will fail. Code that is not just in core, > but in request, filed, and most other stream libraries that use nextTick() > as a way to process data before IO to check the state of the stream, all > fail under load. All of them, without a doubt, fail under load because of > this issue. Forget about all the code you think might need to change after > Isaac's proposed changes, far more code is broken now under load than will > break in the future with the change. > > Saying that this is just a problem for "people under load", and they can > solve this themselves, isn't good enough, that's what Python and Ruby do > and we're better than that. All node programs and libraries that use APIs > in the way they are recommended should work under load. If they don't then > that is EXACTLY what core is suppose to fix. > > I didn't say we shouldn't solve this problem or that people under load should solve it themselves. Stop saying that. The opposition here is not that "everything is fine", but that we would prefer a solution to this problem that does not change the semantics of nextTick in this way. I even asked what other ones we could consider. 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. Libraries can update their internal implementation and still provide some level of confidence that their semantics are unchanged. So if request started using some new solution, no one using it would have to change their code. Most people wouldn't have to care, their stuff would just happen to work better if they find themselves in the situation where this problem would've arisen. Is that not accurate? I'm certainly missing something about the above argument. :Marco -- Marco Rogers [email protected] | https://twitter.com/polotek Life is ten percent what happens to you and ninety percent how you respond to it. - Lou Holtz
