Skip to content
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

Use native-or-bluebird promises #12

Closed
jamestalmage opened this issue Oct 18, 2015 · 0 comments · Fixed by #13
Closed

Use native-or-bluebird promises #12

jamestalmage opened this issue Oct 18, 2015 · 0 comments · Fixed by #13
Assignees

Comments

@jamestalmage
Copy link
Collaborator

Apparently there are still some issues with V8's implementation of promises (and others):

  1. Aggressive Memory Leak tj/co#180
  2. chain of never resolved promises create memory leaks promises-aplus/promises-spec#179
  3. Fix memory leak then/promise#67
  4. Potential memory leak petkaantonov/bluebird#296

Specifically, the following code quickly blows up with Native Promise implementations (I tried 0.12.7, and 4.1.2 native promises).

function run(i) {
    return  new Promise(function(resolve) {
        setImmediate(resolve);
    }).then(function () {
      return i < 99999999 ? run(i + 1) : i;
    });
}
run(0).then(function (result) {
  console.log(result);
});

This has apparently been fixed in bluebird. I can't find the specific PR, but the above code chugs along (seemingly endlessly) and does not throw when using bluebird. Also, some highly unscientific benchmarking suggests a 2x / 3x performance increase using bluebird (this is echoed by a number of comments I came across on GitHub and SO).

The native-or-bluebird package is really small. It:

  1. Checks for bluebird and returns that if found.
  2. Checks for native and returns that if found.
  3. Throws or returns undefined (depending on how you require it).
jamestalmage added a commit that referenced this issue Oct 19, 2015
I released [email protected] a bit prematurely, and have already
cut 3.0.0. It now handles a number of corner cases we were handling
manually:

 1. Ensure callbacks are only called once
 2. Require a promise implementation if no callback is provided
 3. Ensure callbacks are called async

And a few we were missing:

 1. Look for `bluebird` and fallback to native promises
 2. Supress `unhandledRejection` notices on promises if user provides a callback (assumes the callback handles errors).
 3. Consistent behavior if they return a promise that is rejected with `null` / `undefined`
 4. Minor performance boost by only binding deferred.resolve/deferred.reject methods as needed

Closes #12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants