I should probably not use words unless I'm sure what they mean :) Pardon my ignorance a bit here. I probably need to be educated about this subject. I've got a few comments though.
What I mean is that if this change happens, the potential for exploding call stack should be handled. I think the trampoline technique is one way to do that. But if I understand it correctly using a generic trampoline to kill the stack at some predetermined time would just make things messy. Forget trampolines. The more I think about the original problem, the more I think nextTick does exactly what it should do, and we need something else to ensure that people don't miss data. setImmediate seems a likely candidate. But it's not clear to me how the semantics differ from setTimeout(0). What I'm hearing is that the way it will work in node is that a callback set with setTimeout will go on the current tick queue immediately. So it will be guaranteed to be executed and run to completion before the event loop yields to any i/o operations. Is that accurate? If that is accurate, how does it compare to the implementation proposed by Microsoft and implemented in IE (http://ie.microsoft.com/testdrive/Performance/setImmediateSorting/Default.html)? If they're not exactly the same semantics, that could create some compatibility problems. It also looks like setImmediate is not in going to be standardized. For that reason I would recommend putting it on the process namespace instead of a free global. If it ever does become a standard, it'll be easier to stay backwards compatible by sticking the new version onto process. As for the potential for recursive callbacks. Isaac makes a good case that it's seems the same normal infinite recursion. But this is not a normal environment and doesn't look like normal recursion. I think it's very likely people will mistakenly do this. Especially since we've been training people that when you do nextTick or setTimeout/setInterval, that it won't lock up your event loop. For instance, this is a common js pattern. var doThing = function() { // do some thing interesting setTimeout(doThing, delay); } setTimeout(doThing, delay) This is an alternate pattern to setInterval that makes sure your current job is complete before re-running. But we tell people that "nextTick is like setTimeout, only more efficient". So in node, people do this. var doThing = function() { // do some thing interesting process.nextTick(doThing); } process.nextTick(doThing); With the proposed change, this will now starve your event loop right? But it looks perfectly reasonable. If your program locks up or you get an Error from this, that would definitely violate least surprise in my mind. Avoiding starving the event loop is critical to a working node program. With this change, that task is just a little harder. :Marco On Sunday, May 27, 2012 3:49:55 PM UTC-7, Jorge wrote: > > On May 27, 2012, at 8:38 PM, Marco Rogers wrote: > > > Early post cause I'm on my phone. In short, I think the new behavior > should definitely have trampoline behavior to prevent starvation. > > What do trampolines have to do with starvation? > > -- > Jorge.
