async-lock - npm Package Compare versions

Comparing version 1.1.0 to 1.1.1

History.md

		@@ -0,1 +1,5 @@
		1.1.1 / 2018-02-14
		==================
		* Fix result Promise not resolving when locking empty key array

		1.1.0 / 2017-10-17
		@@ -2,0 +6,0 @@ ==================

lib/index.js

		@@ -206,10 +206,15 @@ 'use strict';
		var deferred = this._deferPromise();
		fnx(function (err, ret) {
		if (err) {
		deferred.reject(err);
		}
		else {
		deferred.resolve(ret);
		}
		});
		// check for promise mode in case keys is empty array
		if (fnx.length === 1) {
		fnx(function (err, ret) {
		if (err) {
		deferred.reject(err);
		}
		else {
		deferred.resolve(ret);
		}
		});
		} else {
		deferred.resolve(fnx());
		}
		return deferred.promise;
		@@ -216,0 +221,0 @@ }

package.json

		{
		"name": "async-lock",
		"description": "Lock on asynchronous code",
		"version": "1.1.0",
		"version": "1.1.1",
		"author": {
		@@ -6,0 +6,0 @@ "name": "Rogier Schouten",

README.md

		@@ -14,5 +14,13 @@ # async-lock

		## Why you need locking on single threaded nodejs?
		## Disclaimer

		Nodejs is single threaded, and the code execution is never get interrupted inside an event loop, so locking is unnecessary? This is true ONLY IF your critical section can be executed inside a single event loop.
		I did not create this package, and I will not add any features to it myself. I was granted the ownership because it was no longer being
		maintained, and I volunteered to fix a bug.

		If you have a new feature you would like to have incorporated, please send me a PR and I will be happy to work with you and get it merged.
		For any bugs, PRs are most welcome but when possible I will try to get them resolved as soon as possible.

		## Why do you need locking on single threaded nodejs?

		Nodejs is single threaded, and the code execution never gets interrupted inside an event loop, so locking is unnecessary? This is true ONLY IF your critical section can be executed inside a single event loop.
		However, if you have any async code inside your critical section (it can be simply triggered by any I/O operation, or timer), your critical logic will across multiple event loops, therefore it's not concurrency safe!
		@@ -19,0 +27,0 @@

.npmignore

AUTHORS

Sorry, the diff of this file is not supported yet

New alerts