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.
>> 
>> 

Reply via email to