interaction between setScheduler, longStackTraces, and async trampoline

[metamatt]

I'm trying to use Bluebird alongside Angular 1.4 to replace Angular's $q (a la this suggestion).

I found that actions taken in a promise.then handler don't always get digested unless I trigger a digest cycle. I stepped around the Bluebird code a bit to see how the result of setScheduler was used, and it seems to be honored only if async._trampolineEnabled is true. And if I'm reading the code correctly, use of Promise.longStackTraces() in Chrome automatically disables the trampoline.

I'm new to this project so don't know the history with the trampoline, the Async abstraction, etc but I think I agree with the spin in the README.md on the sync build: don't use it (i.e. things are best with the trampoline enabled).

Also I noticed that calling Promise.enableTrampoline() implicitly re-enables the default scheduler, so if Promise.setScheduler() had previously been set, now it won't be.

Is it possible to make these features (long stack traces and setScheduler) work better together? (I see #542 but I don't know what the issue was there and the link is broken so it's hard to piece together the story starting now).

[petkaantonov]

It's basically not possible to implement invokeLater if trampoline is disabled. So when it is disabled, setTimeout is used as it's somewhat possible to reasonably emulate invokeLaterjust by using a huge timeout for invokeLater and small timeout for invoke. That's why it's not possible to use a custom scheduler when trampoline is disabled.

On the other hand, if trampoline is enabled, then Chrome DevTools won't show correct async stack trace (although the one logged on console is correct).

[petkaantonov]

It's basically not possible to implement invokeLater if trampoline is disabled. So when it is disabled, setTimeout is used as it's somewhat possible to reasonably emulate invokeLaterjust by using a huge timeout for invokeLater and small timeout for invoke. That's why it's not possible to use a custom scheduler when trampoline is disabled.

On the other hand, if trampoline is enabled, then Chrome DevTools won't show correct async stack trace (although the one logged on console is correct).

[benjamingr]

@petkaantonov but can't bluebird call the scheduler for each function?

Do async stack traces work with $q?

I wonder if this should perhaps be an option in 3.0

[benjamingr]

@petkaantonov but can't bluebird call the scheduler for each function?

Do async stack traces work with $q?

I wonder if this should perhaps be an option in 3.0

[petkaantonov]

@benjamingr no as I explained above

[petkaantonov]

@benjamingr no as I explained above

[benjamingr]

Why? Wouldn't it just mean running whatever the scheduler is for each function instead of setTimeout?

[benjamingr]

Why? Wouldn't it just mean running whatever the scheduler is for each function instead of setTimeout?

[petkaantonov]

we discussed offline and this could be done by implementing invoke like this

this.schedule(fn);

and invokeLater like this

this.schedule(function() {
    setTimeout(fn, 100);
});

when trampoline is disabled

[petkaantonov]

we discussed offline and this could be done by implementing invoke like this

this.schedule(fn);

and invokeLater like this

this.schedule(function() {
    setTimeout(fn, 100);
});

when trampoline is disabled

[petkaantonov]

Fixed in 2.9.28

[petkaantonov]

Fixed in 2.9.28