-
Notifications
You must be signed in to change notification settings - Fork 99
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
Safely handle parallel/concurrent invocations #957
Comments
I can reproduce. Lock file sounds reasonable to me. I'm only concerned about situations where fpm hits an unhandled exception and leaves the lock file behind. Is there a way to handle that? |
Interesting enhancement @everythingfunctional. I think the proposed solution looks very reasonable. Could that be done on a per-dependency basis? (think something similar to I think we also want to understand what causes this:
because we could figure out a fix and force a full rebuild if something went corrupt. Edit: also see rust-lang/cargo#354 |
Yep, that's the main danger. If you wanted to get fancy the lock file could contain the PID of the process that created, and then check if that process is still executing, if not delete it and create a new one. Basically, there are solutions.
The compiler stepping on its own toes, but updating the timestamp of files anyways. I.e. it looks like the object/mod file got produced after the source code was updated, but it didn't get produced correctly. |
FYI, my use case is trying to get |
Description
At present, if you invoke fpm on the same project multiple times in parallel, the compiler will trip over itself as it tries to compile the same files at the same time, and can leave the project in an inconsistent state such that subsequent invocations do not try to rebuild when they should. If possible, fpm should avoid trying to build a project multiple times in parallel.
Possible Solution
A quick and dirty solution would be to create a "lock file" on fpm startup and delete it on program shutdown. If the "lock file" is already present, just wait until it's removed. It's not flawless, but could be sufficient.
Additional Information
No response
The text was updated successfully, but these errors were encountered: