{
  "name": "asap",
  "version": "1.0.0",
  "description": "High-priority task queue for Node.js and browsers",
  "keywords": [
    "event",
    "task",
    "queue"
  ],
  "licenses": [
    {
      "type": "MIT",
      "url": "https://github.com/kriskowal/asap/raw/master/LICENSE.md"
    }
  ],
  "main": "asap",
  "readme": "\n# ASAP\n\nThis `asap` CommonJS package contains a single `asap` module that\nexports a single `asap` function that executes a function **as soon as\npossible**.\n\n```javascript\nasap(function () {\n    // ...\n});\n```\n\nMore formally, ASAP provides a fast event queue that will execute tasks\nuntil it is empty before yielding to the JavaScript engine's underlying\nevent-loop.  When the event queue becomes non-empty, ASAP schedules a\nflush event, preferring for that event to occur before the JavaScript\nengine has an opportunity to perform IO tasks or rendering, thus making\nthe first task and subsequent tasks semantically indistinguishable.\nASAP uses a variety of techniques to preserve this invariant on\ndifferent versions of browsers and NodeJS.\n\nBy design, ASAP can starve the event loop on the theory that, if there\nis enough work to be done synchronously, albeit in separate events, long\nenough to starve input or output, it is a strong indicator that the\nprogram needs to push back on scheduling more work.\n\nTake care.  ASAP can sustain infinite recursive calls indefinitely\nwithout warning.  This is behaviorally equivalent to an infinite loop.\nIt will not halt from a stack overflow, but it *will* chew through\nmemory (which is an oddity I cannot explain at this time).  Just as with\ninfinite loops, you can monitor a Node process for this behavior with a\nheart-beat signal.  As with infinite loops, a very small amount of\ncaution goes a long way to avoiding problems.\n\n```javascript\nfunction loop() {\n    asap(loop);\n}\nloop();\n```\n\nASAP is distinct from `setImmediate` in that it does not suffer the\noverhead of returning a handle and being possible to cancel.  For a\n`setImmediate` shim, consider [setImmediate][].\n\n[setImmediate]: https://github.com/noblejs/setimmediate\n\nIf a task throws an exception, it will not interrupt the flushing of\nhigh-priority tasks.  The exception will be postponed to a later,\nlow-priority event to avoid slow-downs, when the underlying JavaScript\nengine will treat it as it does any unhandled exception.\n\n## Heritage\n\nASAP has been factored out of the [Q][] asynchronous promise library.\nIt originally had a naïve implementation in terms of `setTimeout`, but\n[Malte Ubl][NonBlocking] provided an insight that `postMessage` might be\nuseful for creating a high-priority, no-delay event dispatch hack.\nSince then, Internet Explorer proposed and implemented `setImmediate`.\nRobert Kratić began contributing to Q by measuring the performance of\nthe internal implementation of `asap`, paying particular attention to\nerror recovery.  Domenic, Robert, and I collectively settled on the\ncurrent strategy of unrolling the high-priority event queue internally\nregardless of what strategy we used to dispatch the potentially\nlower-priority flush event.  Domenic went on to make ASAP cooperate with\nNodeJS domains.\n\n[Q]: https://github.com/kriskowal/q\n[NonBlocking]: http://www.nonblocking.io/2011/06/windownexttick.html\n\nFor further reading, Nicholas Zakas provided a thorough article on [The\nCase for setImmediate][NCZ].\n\n[NCZ]: http://www.nczonline.net/blog/2013/07/09/the-case-for-setimmediate/\n\n## License\n\nCopyright 2009-2013 by Contributors\nMIT License (enclosed)\n\n",
  "readmeFilename": "README.md",
  "_id": "asap@1.0.0",
  "dist": {
    "shasum": "b2a45da5fdfa20b0496fc3768cc27c12fa916a7d"
  },
  "_from": "asap@~1.0.0",
  "_resolved": "https://registry.npmjs.org/asap/-/asap-1.0.0.tgz"
}
