-
-
Notifications
You must be signed in to change notification settings - Fork 146
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
Perhaps there is an iterative approach instead of recursive? #22
Comments
We might be able to put a trampoline inside then or resolve to keep the stack size constant. |
👍 |
Here's a trimmed down stack trace that shows where the recursion is happening:
|
I think @igorw is right: using a trampoline with promise resolution should be possible. It looks like bluebird uses trampolines, and here's a proof of concept promises implementation that uses trampolines: https://gist.github.com/Twisol/4526419. |
I played a little bit: https://github.com/reactphp/promise/compare/queue |
Since the queue implementation only reduces recursion per each promise chain, i also played with a global queue: https://github.com/reactphp/promise/compare/global-queue. It's a little bit more difficult because I also realized, that introducing a queue opens the possibility to implement future-turn resolutions (#4). |
Interesting. How would you envision the global queue technique working with something like React? Would it just drain the task queue on each tick? |
Exactly, |
This library currently uses recursion for promise chain resolution. Using a promise and chaining off of the promise potentially forever, will cause a stack overflow due to deep recursion.
Here's a really contrived example:
Running this code will show that the stack depth grows significantly for each promise resolution:
I don't usually use XDebug's default nesting limit of 100, but this illustrates the point that this library provides a recursive solution. I wonder if there is a way to implement promise resolution iteratively.
@jsor Have you ever attempted this or considered an iterative approach? It seems like some kind of directed acyclic graph structure that branches off of the deferred() would allow for an iterative approach.
The text was updated successfully, but these errors were encountered: