New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
interaction between setScheduler, longStackTraces, and async trampoline #650
Comments
It's basically not possible to implement 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 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 no as I explained above |
Why? Wouldn't it just mean running whatever the scheduler is for each function instead of |
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 |
Fixed in 2.9.28 |
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 ofPromise.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 ifPromise.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).
The text was updated successfully, but these errors were encountered: