NewYour coding agent can read the release notes before it upgrades.Set up the MCP server →
npm · #2901 most downloaded on npm
A mutex for guarding async workflows
Last release 3 years ago
no release in 18 months
Release timing varies
gaps range from 8 days to 1.4 years
Nearly every release is documented
notes for 18 of 18 stable releases
Nothing withdrawn
no release was ever pulled
10 years old
18 releases · first in 2016
Changelog, bump version.
Changelog, bump version.
Node 14 has long gone the way of the dinosaur.
Node 14 has long gone the way of the dinosaur.
withTimeout.One column per quarter.
This is a full rewrite of the core implementation.
This is a full rewrite of the core implementation.
semaphore.acquire and semaphore.runExclusive.
A waiter will be dispatched once the value of the semaphore is greater or
equal to its weight.semaphore.getValue and semaphore.setValue.semaphore.waitForUnlock. The promise will only resolve
once the value of the semaphore is greater or equal to its weight.waitForUnlock once no waiters remain (fixes #52).waitForUnlock times out if the withTimeout decorator is used.Add waitForUnlock for waiting until a mutex/semaphore is free for locking, thanks to Jason Gore.
waitForUnlock for waiting until a mutex/semaphore is free for locking,
thanks to Jason Gore.Changelog, bump version.
Changelog, bump version.
withTimeout: make Jest happy and cancel timer when the mutex is acquired.
Thanks to cantoine for the PR.Deprecate Mutex::release / Semaphore::release and remove them from the documentation. The methods are still available in 0.3.x, but will be removed in…
Deprecate Mutex::release / Semaphore::release and remove them from the
documentation. The methods are still available in 0.3.x, but will be removed in
0.4.0.
I don't like breaking existing APIs, but using those methods is inherently dangerous as they can accidentally release locks acquired in a completely different place. Furthermore, they are mostly useless for semaphores. I consider adding them an unfortunate mistake on my end.
A safe alternative is the usage of runExclusive which allows to execute
blocks exclusively and automatically manages acquiring and releasing the
mutex or semaphore.
Add Mutex::cancel / Semaphore::cancel for rejecting all currently pending
locks.
Add tryAcquire decorator for lock-or-fail semantics.
Fix a nasty bug related to consecutive calls to Mutex::release.
Mutex::release.Nothing new thanks to NPM. Go away. Install 0.2.6.
Forbid Semaphore::release for concurrency > 1, documentation, bump ve…
Forbid Semaphore::release for concurrency > 1, documentation, bump ve…
Changelog, bump version.
Changelog, bump version.
Improve compatibility with older versions of node 13, thanks to @josemiguelmelo
* Remove sourcemaps
Add a Semaphore, reimplement Mutex on top of it
Semaphore, reimplement Mutex on top of itwithTimeout decorator that limits the time the program waits
for the mutex or semaphore to become availableDocumentation updates (thanks to hmil and 0xflotus)
Move deps to devDependencies (thanks to Meirion Hughes for the PR)
* Move to yarn * Add tslint * Switch tests to use ES6 * Add isLocked()
* Fix documentation for acquire
acquire* Initial release
Your coding agent can read these notes before it upgrades. Set up the MCP server →