		@@ -34,3 +34,4 @@ #!/usr/bin/env node
		ppc64: true,
		ppc: true
		ppc: true,
		s390x: true
		}.hasOwnProperty(arch)) {
		@@ -37,0 +38,0 @@ console.error('Unsupported (?) architecture: `' + arch + '`');

package.json

		{
		"name": "deasync",
		"version": "0.1.9",
		"version": "0.1.10",
		"description": "Turns async function into sync via JavaScript wrapper of Node event loop",
		@@ -5,0 +5,0 @@ "main": "index.js",

README.md

		@@ -11,6 +11,6 @@ DeAsync.js
		Suppose you maintain a library that exposes a function <code>getData</code>. Your users call it to get actual data:
		<code>var output = getData();</code>
		<code>var myData = getData();</code>
		Under the hood data is saved in a file so you implemented <code>getData</code> using Node.js built-in <code>fs.readFileSync</code>. It's obvious both <code>getData</code> and <code>fs.readFileSync</code> are sync functions. One day you were told to switch the underlying data source to a repo such as MongoDB which can only be accessed asynchronously. You were also told to avoid pissing off your users, <code>getData</code> API cannot be changed to return merely a promise or demand a callback parameter. How do you meet both requirements?

		You may tempted to use [node-fibers](https://github.com/laverdet/node-fibers) or a module derived from it, but node fibers can only wrap async function call into a sync function inside a fiber. In the case above you cannot assume all callers are inside fibers. On the other hand, if you start a fiber in `getData` then `getData` itself will still return immediately without waiting for the async call result. For similar reason ES6 generators introduced in Node v11 won't work either.
		You may tempted to use [node-fibers](https://github.com/laverdet/node-fibers) or a module derived from it, but node fibers can only wrap async function call into a sync function inside a fiber. In the case above you cannot assume all callers are inside fibers. On the other hand, if you start a fiber in `getData` then `getData` itself will still return immediately without waiting for the async call result. For similar reason ES6 generators introduced in Node v0.11 won't work either.

		@@ -17,0 +17,0 @@ What really needed is a way to block subsequent JavaScript from running without blocking entire thread by yielding to allow other events in the event loop to be handled. Ideally the blockage is removed as soon as the result of async function is available. A less ideal but often acceptable alternative is a `sleep` function which you can use to implement the blockage like ```while(!done) sleep(100);```. It is less ideal because sleep duration has to be guessed. It is important the `sleep` function not only shouldn't block entire thread, but also shouldn't incur busy wait that pegs the CPU to 100%.

deasync - npm Package Compare versions

New alerts

Fixed alerts

Improved metrics