Use custom mutex implementation instead of async-mutex#900
Merged
Conversation
🦋 Changeset detectedLatest commit: 465b193 The changes in this PR will be included in the next version bump. This PR includes changesets to release 10 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
stevensJourney
approved these changes
Mar 18, 2026
Collaborator
stevensJourney
left a comment
There was a problem hiding this comment.
I'm happy with these changes. Removing a dependency is always nice, removing it and replacing it with even more functionality is even better :)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
To serialize some operations within a JavaScript context, we currently rely on the
async-mutexpackage. That package is great, but we have some use-cases that are tricky to implement with it. In particular, it doesn't support timeouts (well, it does, but only globally on a mutex and we need per-acquire timeouts). Our workaround so far is to either ignore the timeout, or to acquire the mutex and then return it immediately if the timeout has expired. This is not a particularly good timeout implementation since we still need to wait for the mutex once even if the timeout has elapsed. It also doesn't support aborting an individual mutex request.For the JS worker refactoring (#889) which introduces local mutexes where we've previously used navigator locks (with proper aborts), relying on
async-mutexand ignoring timeouts would be a regression. So, considering thatasync-mutexdoesn't do exactly what we need and since writing async mutexes in single-threaded languages is not that hard, this rolls our own mutex implementation. For the most part, it has the exact same API asasync-mutex:acquire()locks the mutex, and returns a function that unlocks it when invoked.runExclusivehelper invokes a callback while them mutex is locked.Because some of our mutex invocations rely on abort signals and others rely on timeouts, I've added an
AbortSignal-based abort strategy to the implementation. In places where we've previously been using timeouts, the newtimeoutSignalfunction is a wrapper aroundAbortSignal.timeoutthat should work in all places.