FYI: setImmediate === nextTick and identical to a setTimeout(f,0) without the
clamping.
--
Jorge.
On May 29, 2012, at 10:45 PM, Isaac Schlueter wrote:
> Computationally expensive stuff should be done in a child process, or
> a uv_work_t thread in an addon. nextTick is a bad fit for this.
> setTimeout(fn, 0) is not quite as bad, but it is slower.
>
> We can look into adding a setImmediate function for 0.9 that matches
> the semantics of the web browser. The intent of setImmediate is to be
> used for cases like this, and it should be pretty easy to implement.
>
> On Tue, May 29, 2012 at 1:31 PM, Mikeal Rogers <mikeal.rog...@gmail.com>
> wrote:
>> I have never seen nextTick recommended for breaking up computationally
>> expensive tasks, this is what cluster and child_process are for.
>>
>> Also, setTimeout(cb,0) is very efficient in node and does not suffer the
>> penalties we are familiar with from the browser. It's actually a better fit
>> for this use case than nextTick().
>>
>> -Mikeal
>>
>>
>> On May 29, 2012, at May 29, 201212:23 PM, Bruno Jouhier wrote:
>>
>> +1
>>
>> nextTick is the efficient way to yield to another "thread of processing"
>> (thread between quotes of course) when performing an expensive computation.
>> So it is the antidote to starvation and thus a very useful call.
>>
>> If you change its behavior, you should at least provide a replacement call
>> which will be at least as efficient (unlike setTimeout(cb, 0)). And then why
>> not keep nextTick as is and introduce another call with a different name
>> (like afterTick as someone suggested) if you really need one.
>>
>>
>> On Tuesday, May 29, 2012 2:43:20 AM UTC+2, phidelta wrote:
>>>
>>> I think that the current semantics have value. I use nextTick when I
>>> want to ensure that io can happen between the invocation and the
>>> ticked call. As well as to work with a new call stack.
>>>
>>> For example when I emit an event whose lister also emits an event and
>>> so on, I create a potentially long chain of stuff that can happen
>>> within a tick. So when I emit from within a listener I usually
>>> nextTick the emit to allow io in between.
>>>
>>> So if you change nextTick to really mean "at the end of this tick", at
>>> least we will want a function like reallyNextTick that keeps the
>>> current behavior. Of course I would need to do a search replace over a
>>> lot of code, but I could live with that.
>>>
>>>
>>> On May 26, 7:50 pm, Isaac Schlueter <i...@izs.me> wrote:
>>>> How would you feel about changing the semantics of process.nextTick
>>>> such that the nextTick queue is *always* cleared after every v8
>>>> invocation, guaranteeing that a nextTick occurs before any IO can
>>>> happen?
>>>>
>>>> This would imply that you can starve the event loop by doing nextTick.
>>>> So, for example, the timeout would never fire in this code:
>>>>
>>>> setTimeout(function () {
>>>> console.log('timeout')})
>>>>
>>>> process.nextTick(function f () {
>>>> process.nextTick(f)
>>>>
>>>> })
>>>>
>>>> Reasoning:
>>>>
>>>> We have some cases in node where we use a nextTick to give the user a
>>>> chance to add event handlers before taking some action. However,
>>>> because we do not execute nextTick immediately (since that would
>>>> starve the event loop) you have very rare situations where IO can
>>>> happen in that window.
>>>>
>>>> Also, the steps that we go through to prevent nextTick starvation, and
>>>> yet try to always have nextTick be as fast as possible, results in
>>>> unnecessarily convoluted logic.
>>>>
>>>> This isn't going to change for v0.8, but if no one has a use-case
>>>> where it's known to break, we can try it early in v0.9.
>>
>>
