-
-
Notifications
You must be signed in to change notification settings - Fork 316
Fix memory leak #67
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
Fix memory leak #67
Conversation
P.S. don't merge this yet. We should make "handle" some kind of private symbol if we are going to take this approach. |
just for note, there is an observable difference that may or may not be tolerable. |
That's interesting. I think that probably is tolerable, but I do wonder if we could fix that somehow. |
@ForbesLindesay I've been contemplating doing this for a long time, and I probably have a local branch around doing a similar thing. Collapsing promise chains like this should be a nice perf boost. |
I think depending on es6-symbol and sticking everything under |
The encapsulation is just as good if we use es6-symbol on |
Sure, but |
e28c311
to
5c2f0e4
Compare
5c2f0e4
to
fa3a970
Compare
This fixes problems with very nested promises without recreating the memory leak
I now believe this is ready to merge, and it fixes a major memory leak. @nathan7 if you can review this asap and do the honours, that would be great. |
I'm merging this now to get unblocked, but I'd still love a review if someone gets a chance. |
Looks good to me, @ForbesLindesay! Clever trick with the |
This is a crude attempt at fixing the memory leak caused by code like:
In theory this should be a viable way of running a continuous polling operation.