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.
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
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 wrote:
>
> O
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 unde
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 t
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, bu
What is lost here is that you're doing something you shouldn't if you starve IO
this way.
We need a guard, no doubt, but I think it should throw so people can fix this,
not try to let some IO in with 1 second of bad processing in between each.
-Mikeal
On May 27, 2012, at May 27, 201211:38 AM,
Early post cause I'm on my phone. In short, I think the new behavior should
definitely have trampoline behavior to prevent starvation.
I'm afraid the loop starving scenario will come up more often than you think.
Peo
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
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 wrote:
> And the proper name IMO would be *this*Tick not *next*Tic
+1
I thought it worked like that. I believe it should. However following:
process.nextTick(function () { console.log(1); });
process.nextTick(function () { console.log(2); });
Should output 1, 2 not 2, 1
On Sunday, May 27, 2012 1:50:20 AM UTC+2, Isaac Schlueter wrote:
>
> How would you feel ab
On May 27, 2012, at 6:30 AM, Tim Caswell wrote:
> There are already many ways to starve/block the event loop.
>
> You could have an infinite loop
>
> while (true) {}
>
> Or a recursive loop that blocks till the stack overflows
>
> function a() {
> a();
> }
> a();
>
> Now these new semantics
13 matches
Mail list logo
