{ "name": "bluebird", "description": "Full featured Promises/A+ implementation with exceptionally good performance", "version": "2.9.24", "keywords": [ "promise", "performance", "promises", "promises-a", "promises-aplus", "async", "await", "deferred", "deferreds", "future", "flow control", "dsl", "fluent interface" ], "scripts": { "lint": "node scripts/jshint.js", "test": "node tools/test.js", "istanbul": "istanbul", "prepublish": "node tools/build.js --no-debug --main --zalgo --browser --minify" }, "homepage": "https://github.com/petkaantonov/bluebird", "repository": { "type": "git", "url": "git://github.com/petkaantonov/bluebird.git" }, "bugs": { "url": "http://github.com/petkaantonov/bluebird/issues" }, "license": "MIT", "author": { "name": "Petka Antonov", "email": "petka_antonov@hotmail.com", "url": "http://github.com/petkaantonov/" }, "devDependencies": { "acorn": "~0.6.0", "baconjs": "^0.7.43", "bluebird": "^2.9.2", "body-parser": "^1.10.2", "browserify": "^8.1.1", "cli-table": "~0.3.1", "co": "^4.2.0", "cross-spawn": "^0.2.3", "glob": "^4.3.2", "grunt-saucelabs": "~8.4.1", "highland": "^2.3.0", "istanbul": "^0.3.5", "jshint": "^2.6.0", "jshint-stylish": "~0.2.0", "mkdirp": "~0.5.0", "mocha": "~2.1", "open": "~0.0.5", "optimist": "~0.6.1", "rimraf": "~2.2.6", "rx": "^2.3.25", "serve-static": "^1.7.1", "sinon": "~1.7.3", "uglify-js": "~2.4.16" }, "readmeFilename": "README.md", "main": "./js/main/bluebird.js", "browser": "./js/browser/bluebird.js", "files": [ "js/browser", "js/main", "js/zalgo", "LICENSE", "zalgo.js" ], "readme": "\n \"Promises/A+\n\n[![Build Status](https://travis-ci.org/petkaantonov/bluebird.svg?branch=master)](https://travis-ci.org/petkaantonov/bluebird)\n[![coverage-98%](http://img.shields.io/badge/coverage-98%-brightgreen.svg?style=flat)](http://petkaantonov.github.io/bluebird/coverage/debug/index.html)\n\n\n# Introduction\n\nBluebird is a fully featured [promise](#what-are-promises-and-why-should-i-use-them) library with focus on innovative features and performance\n\n\n\n# Topics\n\n- [Features](#features)\n- [Quick start](#quick-start)\n- [API Reference and examples](API.md)\n- [Support](#support)\n- [What are promises and why should I use them?](#what-are-promises-and-why-should-i-use-them)\n- [Questions and issues](#questions-and-issues)\n- [Error handling](#error-handling)\n- [Development](#development)\n - [Testing](#testing)\n - [Benchmarking](#benchmarks)\n - [Custom builds](#custom-builds)\n - [For library authors](#for-library-authors)\n- [What is the sync build?](#what-is-the-sync-build)\n- [License](#license)\n- [Snippets for common problems](https://github.com/petkaantonov/bluebird/wiki/Snippets)\n- [Promise anti-patterns](https://github.com/petkaantonov/bluebird/wiki/Promise-anti-patterns)\n- [Changelog](changelog.md)\n- [Optimization guide](#optimization-guide)\n\n# Features\n\"bluebird\n\n- [Promises A+](http://promisesaplus.com)\n- [Synchronous inspection](API.md#synchronous-inspection)\n- [Concurrency coordination](API.md#collections)\n- [Promisification on steroids](API.md#promisification)\n- [Resource management through a parallel of python `with`/C# `using`](API.md#resource-management)\n- [Cancellation and timeouts](API.md#cancellation)\n- [Parallel for C# `async` and `await`](API.md#generators)\n- Mind blowing utilities such as\n - [`.bind()`](API.md#binddynamic-thisarg---promise)\n - [`.call()`](API.md#callstring-propertyname--dynamic-arg---promise)\n - [`Promise.join()`](API.md#promisejoinpromisethenablevalue-promises-function-handler---promise)\n - [And](API.md#core) [much](API.md#timers) [more](API.md#utility)!\n- [Practical debugging solutions and sane defaults](#error-handling)\n- [Sick performance](benchmark/)\n\n
\n\n# Quick start\n\n## Node.js\n\n npm install bluebird\n\nThen:\n\n```js\nvar Promise = require(\"bluebird\");\n```\n\n## Browsers\n\nThere are many ways to use bluebird in browsers:\n\n- Direct downloads\n - Full build [bluebird.js](https://cdn.jsdelivr.net/bluebird/latest/bluebird.js)\n - Full build minified [bluebird.min.js](https://cdn.jsdelivr.net/bluebird/latest/bluebird.min.js)\n- You may use browserify on the main export\n- You may use the [bower](http://bower.io) package.\n\nWhen using script tags the global variables `Promise` and `P` (alias for `Promise`) become available.\n\nA [minimal bluebird browser build](#custom-builds) is ≈38.92KB minified*, 11.65KB gzipped and has no external dependencies.\n\n*Google Closure Compiler using Simple.\n\n#### Browser support\n\nBrowsers that [implement ECMA-262, edition 3](http://en.wikipedia.org/wiki/Ecmascript#Implementations) and later are supported.\n\n[![Selenium Test Status](https://saucelabs.com/browser-matrix/petka_antonov.svg)](https://saucelabs.com/u/petka_antonov)\n\n**Note** that in ECMA-262, edition 3 (IE7, IE8 etc.) it is not possible to use methods that have keyword names like `.catch` and `.finally`. The [API documentation](API.md) always lists a compatible alternative name that you can use if you need to support these browsers. For example `.catch` is replaced with `.caught` and `.finally` with `.lastly`.\n\nAlso, [long stack trace](API.md#promiselongstacktraces---void) support is only available in Chrome, Firefox and Internet Explorer 10+.\n\nAfter quick start, see [API Reference and examples](API.md)\n\n
\n\n# Support\n\n- Mailing list: [bluebird-js@googlegroups.com](https://groups.google.com/forum/#!forum/bluebird-js)\n- IRC: #promises @freenode\n- StackOverflow: [bluebird tag](http://stackoverflow.com/questions/tagged/bluebird)\n- Bugs and feature requests: [github issue tracker](https://github.com/petkaantonov/bluebird/issues?state=open)\n\n
\n\n# What are promises and why should I use them?\n\nYou should use promises to turn this:\n\n```js\nfs.readFile(\"file.json\", function(err, val) {\n if( err ) {\n console.error(\"unable to read file\");\n }\n else {\n try {\n val = JSON.parse(val);\n console.log(val.success);\n }\n catch( e ) {\n console.error(\"invalid json in file\");\n }\n }\n});\n```\n\nInto this:\n\n```js\nfs.readFileAsync(\"file.json\").then(JSON.parse).then(function(val) {\n console.log(val.success);\n})\n.catch(SyntaxError, function(e) {\n console.error(\"invalid json in file\");\n})\n.catch(function(e) {\n console.error(\"unable to read file\")\n});\n```\n\n*If you are wondering \"there is no `readFileAsync` method on `fs` that returns a promise\", see [promisification](API.md#promisification)*\n\nActually you might notice the latter has a lot in common with code that would do the same using synchronous I/O:\n\n```js\ntry {\n var val = JSON.parse(fs.readFileSync(\"file.json\"));\n console.log(val.success);\n}\n//Syntax actually not supported in JS but drives the point\ncatch(SyntaxError e) {\n console.error(\"invalid json in file\");\n}\ncatch(Error e) {\n console.error(\"unable to read file\")\n}\n```\n\nAnd that is the point - being able to have something that is a lot like `return` and `throw` in synchronous code.\n\nYou can also use promises to improve code that was written with callback helpers:\n\n\n```js\n//Copyright Plato http://stackoverflow.com/a/19385911/995876\n//CC BY-SA 2.5\nmapSeries(URLs, function (URL, done) {\n var options = {};\n needle.get(URL, options, function (error, response, body) {\n if (error) {\n return done(error)\n }\n try {\n var ret = JSON.parse(body);\n return done(null, ret);\n }\n catch (e) {\n done(e);\n }\n });\n}, function (err, results) {\n if (err) {\n console.log(err)\n } else {\n console.log('All Needle requests successful');\n // results is a 1 to 1 mapping in order of URLs > needle.body\n processAndSaveAllInDB(results, function (err) {\n if (err) {\n return done(err)\n }\n console.log('All Needle requests saved');\n done(null);\n });\n }\n});\n```\n\nIs more pleasing to the eye when done with promises:\n\n```js\nPromise.promisifyAll(needle);\nvar options = {};\n\nvar current = Promise.resolve();\nPromise.map(URLs, function(URL) {\n current = current.then(function () {\n return needle.getAsync(URL, options);\n });\n return current;\n}).map(function(responseAndBody){\n return JSON.parse(responseAndBody[1]);\n}).then(function (results) {\n return processAndSaveAllInDB(results);\n}).then(function(){\n console.log('All Needle requests saved');\n}).catch(function (e) {\n console.log(e);\n});\n```\n\nAlso promises don't just give you correspondences for synchronous features but can also be used as limited event emitters or callback aggregators.\n\nMore reading:\n\n - [Promise nuggets](https://promise-nuggets.github.io/)\n - [Why I am switching to promises](http://spion.github.io/posts/why-i-am-switching-to-promises.html)\n - [What is the the point of promises](http://domenic.me/2012/10/14/youre-missing-the-point-of-promises/#toc_1)\n - [Snippets for common problems](https://github.com/petkaantonov/bluebird/wiki/Snippets)\n - [Promise anti-patterns](https://github.com/petkaantonov/bluebird/wiki/Promise-anti-patterns)\n\n# Questions and issues\n\nIf you find a bug in bluebird or have a feature request, file an issue in the [github issue tracker](https://github.com/petkaantonov/bluebird/issues). Anything else, such as questions for help in using the library, should be posted in [StackOverflow](http://stackoverflow.com/questions/tagged/bluebird) under tags `promise` and `bluebird`.\n\n# Error handling\n\nThis is a problem every promise library needs to handle in some way. Unhandled rejections/exceptions don't really have a good agreed-on asynchronous correspondence. The problem is that it is impossible to predict the future and know if a rejected promise will eventually be handled.\n\nThere are two common pragmatic attempts at solving the problem that promise libraries do.\n\nThe more popular one is to have the user explicitly communicate that they are done and any unhandled rejections should be thrown, like so:\n\n```js\ndownload().then(...).then(...).done();\n```\n\nFor handling this problem, in my opinion, this is completely unacceptable and pointless. The user must remember to explicitly call `.done` and that cannot be justified when the problem is forgetting to create an error handler in the first place.\n\nThe second approach, which is what bluebird by default takes, is to call a registered handler if a rejection is unhandled by the start of a second turn. The default handler is to write the stack trace to `stderr` or `console.error` in browsers. This is close to what happens with synchronous code - your code doesn't work as expected and you open console and see a stack trace. Nice.\n\nOf course this is not perfect, if your code for some reason needs to swoop in and attach error handler to some promise after the promise has been hanging around a while then you will see annoying messages. In that case you can use the `.done()` method to signal that any hanging exceptions should be thrown.\n\nIf you want to override the default handler for these possibly unhandled rejections, you can pass yours like so:\n\n```js\nPromise.onPossiblyUnhandledRejection(function(error){\n throw error;\n});\n```\n\nIf you want to also enable long stack traces, call:\n\n```js\nPromise.longStackTraces();\n```\n\nright after the library is loaded.\n\nIn node.js use the environment flag `BLUEBIRD_DEBUG`:\n\n```\nBLUEBIRD_DEBUG=1 node server.js\n```\n\nto enable long stack traces in all instances of bluebird.\n\nLong stack traces cannot be disabled after being enabled, and cannot be enabled after promises have already been created. Long stack traces imply a substantial performance penalty, even after using every trick to optimize them.\n\nLong stack traces are enabled by default in the debug build.\n\n#### Expected and unexpected errors\n\nA practical problem with Promises/A+ is that it models Javascript `try-catch` too closely for its own good. Therefore by default promises inherit `try-catch` warts such as the inability to specify the error types that the catch block is eligible for. It is an anti-pattern in every other language to use catch-all handlers because they swallow exceptions that you might not know about.\n\nNow, Javascript does have a perfectly fine and working way of creating error type hierarchies. It is still quite awkward to use them with the built-in `try-catch` however:\n\n```js\ntry {\n //code\n}\ncatch(e) {\n if( e instanceof WhatIWantError) {\n //handle\n }\n else {\n throw e;\n }\n}\n```\n\nWithout such checking, unexpected errors would be silently swallowed. However, with promises, bluebird brings the future (hopefully) here now and extends the `.catch` to [accept potential error type eligibility](API.md#catchfunction-errorclass-function-handler---promise).\n\nFor instance here it is expected that some evil or incompetent entity will try to crash our server from `SyntaxError` by providing syntactically invalid JSON:\n\n```js\ngetJSONFromSomewhere().then(function(jsonString) {\n return JSON.parse(jsonString);\n}).then(function(object) {\n console.log(\"it was valid json: \", object);\n}).catch(SyntaxError, function(e){\n console.log(\"don't be evil\");\n});\n```\n\nHere any kind of unexpected error will automatically reported on `stderr` along with a stack trace because we only register a handler for the expected `SyntaxError`.\n\nOk, so, that's pretty neat. But actually not many libraries define error types and it is in fact a complete ghetto out there with ad hoc strings being attached as some arbitrary property name like `.name`, `.type`, `.code`, not having any property at all or even throwing strings as errors and so on. So how can we still listen for expected errors?\n\nBluebird defines a special error type `OperationalError` (you can get a reference from `Promise.OperationalError`). This type of error is given as rejection reason by promisified methods when\ntheir underlying library gives an untyped, but expected error. Primitives such as strings, and error objects that are directly created like `new Error(\"database didn't respond\")` are considered untyped.\n\nExample of such library is the node core library `fs`. So if we promisify it, we can catch just the errors we want pretty easily and have programmer errors be redirected to unhandled rejection handler so that we notice them:\n\n```js\n//Read more about promisification in the API Reference:\n//API.md\nvar fs = Promise.promisifyAll(require(\"fs\"));\n\nfs.readFileAsync(\"myfile.json\").then(JSON.parse).then(function (json) {\n console.log(\"Successful json\")\n}).catch(SyntaxError, function (e) {\n console.error(\"file contains invalid json\");\n}).catch(Promise.OperationalError, function (e) {\n console.error(\"unable to read file, because: \", e.message);\n});\n```\n\nThe last `catch` handler is only invoked when the `fs` module explicitly used the `err` argument convention of async callbacks to inform of an expected error. The `OperationalError` instance will contain the original error in its `.cause` property but it does have a direct copy of the `.message` and `.stack` too. In this code any unexpected error - be it in our code or the `fs` module - would not be caught by these handlers and therefore not swallowed.\n\nSince a `catch` handler typed to `Promise.OperationalError` is expected to be used very often, it has a neat shorthand:\n\n```js\n.error(function (e) {\n console.error(\"unable to read file, because: \", e.message);\n});\n```\n\nSee [API documentation for `.error()`](API.md#error-rejectedhandler----promise)\n\nFinally, Bluebird also supports predicate-based filters. If you pass a\npredicate function instead of an error type, the predicate will receive\nthe error as an argument. The return result will be used to determine whether\nthe error handler should be called.\n\nPredicates should allow for very fine grained control over caught errors:\npattern matching, error typesets with set operations and many other techniques\ncan be implemented on top of them.\n\nExample of using a predicate-based filter:\n\n```js\nvar Promise = require(\"bluebird\");\nvar request = Promise.promisify(require(\"request\"));\n\nfunction clientError(e) {\n return e.code >= 400 && e.code < 500;\n}\n\nrequest(\"http://www.google.com\").then(function(contents){\n console.log(contents);\n}).catch(clientError, function(e){\n //A client error like 400 Bad Request happened\n});\n```\n\n**Danger:** The JavaScript language allows throwing primitive values like strings. Throwing primitives can lead to worse or no stack traces. Primitives [are not exceptions](http://www.devthought.com/2011/12/22/a-string-is-not-an-error/). You should consider always throwing Error objects when handling exceptions.\n\n
\n\n#### How do long stack traces differ from e.g. Q?\n\nBluebird attempts to have more elaborate traces. Consider:\n\n```js\nError.stackTraceLimit = 25;\nQ.longStackSupport = true;\nQ().then(function outer() {\n return Q().then(function inner() {\n return Q().then(function evenMoreInner() {\n a.b.c.d();\n }).catch(function catcher(e){\n console.error(e.stack);\n });\n })\n});\n```\n\nYou will see\n\n ReferenceError: a is not defined\n at evenMoreInner (:7:13)\n From previous event:\n at inner (:6:20)\n\nCompare to:\n\n```js\nError.stackTraceLimit = 25;\nPromise.longStackTraces();\nPromise.resolve().then(function outer() {\n return Promise.resolve().then(function inner() {\n return Promise.resolve().then(function evenMoreInner() {\n a.b.c.d()\n }).catch(function catcher(e){\n console.error(e.stack);\n });\n });\n});\n```\n\n ReferenceError: a is not defined\n at evenMoreInner (:7:13)\n From previous event:\n at inner (:6:36)\n From previous event:\n at outer (:5:32)\n From previous event:\n at :4:21\n at Object.InjectedScript._evaluateOn (:572:39)\n at Object.InjectedScript._evaluateAndWrap (:531:52)\n at Object.InjectedScript.evaluate (:450:21)\n\n\nA better and more practical example of the differences can be seen in gorgikosev's [debuggability competition](https://github.com/spion/async-compare#debuggability).\n\n
\n\n# Development\n\nFor development tasks such as running benchmarks or testing, you need to clone the repository and install dev-dependencies.\n\nInstall [node](http://nodejs.org/) and [npm](https://npmjs.org/)\n\n git clone git@github.com:petkaantonov/bluebird.git\n cd bluebird\n npm install\n\n## Testing\n\nTo run all tests, run\n\n node tools/test\n\nIf you need to run generator tests run the `tool/test.js` script with `--harmony` argument and node 0.11+:\n\n node-dev --harmony tools/test\n\nYou may specify an individual test file to run with the `--run` script flag:\n\n node tools/test --run=cancel.js\n\n\nThis enables output from the test and may give a better idea where the test is failing. The paramter to `--run` can be any file name located in `test/mocha` folder.\n\n#### Testing in browsers\n\nTo run the test in a browser instead of node, pass the flag `--browser` to the test tool\n\n node tools/test --run=cancel.js --browser\n\nThis will automatically create a server (default port 9999) and open it in your default browser once the tests have been compiled.\n\nKeep the test tab active because some tests are timing-sensitive and will fail if the browser is throttling timeouts. Chrome will do this for example when the tab is not active.\n\n#### Supported options by the test tool\n\nThe value of boolean flags is determined by presence, if you want to pass false value for a boolean flag, use the `no-`-prefix e.g. `--no-browser`.\n\n - `--run=String`. Which tests to run (or compile when testing in browser). Default `\"all\"`. Can also be a glob string (relative to ./test/mocha folder)\n - `--cover=String`. Create code coverage using the String as istanbul reporter. Coverage is created in the ./coverage folder. No coverage is created by default, default reporter is `\"html\"` (use `--cover` to use default reporter).\n - `--browser` - Whether to compile tests for browsers. Default `false`.\n - `--port=Number` - Whe port where local server is hosted when testing in browser. Default `9999`\n - `--execute-browser-tests` - Whether to execute the compiled tests for browser when using `--browser`. Default `true`.\n - `--open-browser` - Whether to open the default browser when executing browser tests. Default `true`.\n - `--fake-timers` - Whether to use fake timers (`setTimeout` etc) when running tests in node. Default `true`.\n - `--js-hint` - Whether to run JSHint on source files. Default `true`.\n - `--saucelabs` Wheter to create a tunnel to sauce labs and run tests in their VMs instead of your browser when compiling tests for browser.Default `false`.\n\n## Benchmarks\n\nTo run a benchmark, run the given command for a benchmark while on the project root. Requires bash (on windows the mingw32 that comes with git works fine too).\n\nNode 0.11.2+ is required to run the generator examples.\n\n### 1\\. DoxBee sequential\n\nCurrently the most relevant benchmark is @gorkikosev's benchmark in the article [Analysis of generators and other async patterns in node](http://spion.github.io/posts/analysis-generators-and-other-async-patterns-node.html). The benchmark emulates a situation where n amount of users are making a request in parallel to execute some mixed async/sync action. The benchmark has been modified to include a warm-up phase to minimize any JITing during timed sections.\n\nCommand: `bench doxbee`\n\n### 2\\. Made-up parallel\n\nThis made-up scenario runs 15 shimmed queries in parallel.\n\nCommand: `bench parallel`\n\n## Custom builds\n\nCustom builds for browsers are supported through a command-line utility.\n\n\n\n \n \n \n \n \n \n \n \n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n \n
The following features can be disabled
Feature(s)Command line identifier
.any and Promise.anyany
.race and Promise.racerace
.call and .getcall_get
.filter and Promise.filterfilter
.map and Promise.mapmap
.reduce and Promise.reducereduce
.props and Promise.propsprops
.settle and Promise.settlesettle
.some and Promise.somesome
.nodeifynodeify
Promise.coroutine and Promise.spawngenerators
Progressionprogress
Promisificationpromisify
Cancellationcancel
Timerstimers
Resource managementusing
\n\n\nMake sure you have cloned the repo somewhere and did `npm install` successfully.\n\nAfter that you can run:\n\n node tools/build --features=\"core\"\n\n\nThe above builds the most minimal build you can get. You can add more features separated by spaces from the above list:\n\n node tools/build --features=\"core filter map reduce\"\n\nThe custom build file will be found from `/js/browser/bluebird.js`. It will have a comment that lists the disabled and enabled features.\n\nNote that the build leaves the `/js/main` etc folders with same features so if you use the folder for node.js at the same time, don't forget to build\na full version afterwards (after having taken a copy of the bluebird.js somewhere):\n\n node tools/build --debug --main --zalgo --browser --minify\n\n#### Supported options by the build tool\n\nThe value of boolean flags is determined by presence, if you want to pass false value for a boolean flag, use the `no-`-prefix e.g. `--no-debug`.\n\n - `--main` - Whether to build the main build. The main build is placed at `js/main` directory. Default `false`.\n - `--debug` - Whether to build the debug build. The debug build is placed at `js/debug` directory. Default `false`.\n - `--zalgo` - Whether to build the zalgo build. The zalgo build is placed at `js/zalgo` directory. Default `false`.\n - `--browser` - Whether to compile the browser build. The browser build file is placed at `js/browser/bluebird.js` Default `false`.\n - `--minify` - Whether to minify the compiled browser build. The minified browser build file is placed at `js/browser/bluebird.min.js` Default `true`.\n - `--features=String` - See [custom builds](#custom-builds)\n\n
\n\n## For library authors\n\nBuilding a library that depends on bluebird? You should know about a few features.\n\nIf your library needs to do something obtrusive like adding or modifying methods on the `Promise` prototype, uses long stack traces or uses a custom unhandled rejection handler then... that's totally ok as long as you don't use `require(\"bluebird\")`. Instead you should create a file\nthat creates an isolated copy. For example, creating a file called `bluebird-extended.js` that contains:\n\n```js\n //NOTE the function call right after\nmodule.exports = require(\"bluebird/js/main/promise\")();\n```\n\nYour library can then use `var Promise = require(\"bluebird-extended\");` and do whatever it wants with it. Then if the application or other library uses their own bluebird promises they will all play well together because of Promises/A+ thenable assimilation magic.\n\nYou should also know about [`.nodeify()`](API.md#nodeifyfunction-callback---promise) which makes it easy to provide a dual callback/promise API.\n\n
\n\n## What is the sync build?\n\nYou may now use sync build by:\n\n var Promise = require(\"bluebird/zalgo\");\n\nThe sync build is provided to see how forced asynchronity affects benchmarks. It should not be used in real code due to the implied hazards.\n\nThe normal async build gives Promises/A+ guarantees about asynchronous resolution of promises. Some people think this affects performance or just plain love their code having a possibility\nof stack overflow errors and non-deterministic behavior.\n\nThe sync build skips the async call trampoline completely, e.g code like:\n\n async.invoke( this.fn, this, val );\n\nAppears as this in the sync build:\n\n this.fn(val);\n\nThis should pressure the CPU slightly less and thus the sync build should perform better. Indeed it does, but only marginally. The biggest performance boosts are from writing efficient Javascript, not from compromising determinism.\n\nNote that while some benchmarks are waiting for the next event tick, the CPU is actually not in use during that time. So the resulting benchmark result is not completely accurate because on node.js you only care about how much the CPU is taxed. Any time spent on CPU is time the whole process (or server) is paralyzed. And it is not graceful like it would be with threads.\n\n\n```js\nvar cache = new Map(); //ES6 Map or DataStructures/Map or whatever...\nfunction getResult(url) {\n var resolver = Promise.pending();\n if (cache.has(url)) {\n resolver.resolve(cache.get(url));\n }\n else {\n http.get(url, function(err, content) {\n if (err) resolver.reject(err);\n else {\n cache.set(url, content);\n resolver.resolve(content);\n }\n });\n }\n return resolver.promise;\n}\n\n\n\n//The result of console.log is truly random without async guarantees\nfunction guessWhatItPrints( url ) {\n var i = 3;\n getResult(url).then(function(){\n i = 4;\n });\n console.log(i);\n}\n```\n\n# Optimization guide\n\nArticles about optimization will be periodically posted in [the wiki section](https://github.com/petkaantonov/bluebird/wiki), polishing edits are welcome.\n\nA single cohesive guide compiled from the articles will probably be done eventually.\n\n# License\n\nThe MIT License (MIT)\n\nCopyright (c) 2014 Petka Antonov\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in\nall copies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN\nTHE SOFTWARE.\n", "_id": "bluebird@2.9.24", "dist": { "shasum": "ab3f30a7a40c383d14779a63b53aad667cc98ffb" }, "_from": "bluebird@", "_resolved": "https://registry.npmjs.org/bluebird/-/bluebird-2.9.24.tgz" }