-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Safeguard against parallel installs #2146
Comments
Yes, you can do
And it would execute yarn in sequence using a dummy webserver to ensure only one command is active at a time |
@bestander thanks, is there some Yarn documentation WRT the dummy webserver you mentioned? |
@bestander I wrote some code to solve this problem with NPM parallel installs, the way I did it is that each call would write to a persistent queue (a queue with no duplicate commands, duplicates were removed). In this way, only one worker would read from the queue, if the worker had the lock on the queue. If a new worker it will write to the queue, but it if it can't get access to the lock, then the worker just dies, dying with the assumption that the existing worker will take care of the job. The problem with my approach, is that I then cannot block on a call to install a dependency, meaning if I run my postintall script and the worker finishes/dies, it does not mean that the dependency has already been installed. So I think your approach is better :) |
No, sorry, we just needed this feature for one particular case where yarn is used in high concurrency and we could not mutex it externally. |
@bestander are you taking about the yarn website docs for this mutex feature? |
Actually nevermind, there is a doc already https://yarnpkg.com/en/docs/cli/#toc-concurrency-and-mutex |
ok sure np, maybe I will contribute later once i use yarn more |
I ran into this issue last week. I tried This seems like a sane default, since there's no use case for broken concurrent yarn installs. |
right, but what happens if two install commands are run concurrently and the user forgets to use |
To be clear, I meant automatically using a mutex is a sane default. |
BTW, you can add |
@jiaweihli LOL yes "no use case for broken concurrent yarn installs" |
Because there can be multiple installations of NPM dependencies via Yarn, we need to work correctly consider concurrency of Yarn Because Yarn cache could face with problems during concurrent installation, need to limit network concurrency with only 1 instance and use mutex on network yarnpkg/yarn#2146
Because there can be multiple installations of NPM dependencies via Yarn, we need to work correctly consider concurrency of Yarn Because Yarn cache could face with problems during concurrent installation, need to limit network concurrency with only 1 instance and use mutex on network yarnpkg/yarn#2146
On latest version
Just wondering if Yarn will safeguard against this, make sure it's keeping something like this in mind
npm/npm#15137
I assume NPM is, but never known for sure. Probably good for Yarn to safeguard against this as well.
Obviously just replace the code in the npm issue with "yarn add x" instead of "npm install x"
The text was updated successfully, but these errors were encountered: