-
Notifications
You must be signed in to change notification settings - Fork 26.3k
Ngcc better lockfile patch #35934
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
Ngcc better lockfile patch #35934
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just scanned through most of this, given that it has already landed in master, but I do have one comment though. Also, the commit message of separate `SyncLocker` and `LockFile`
refers to "Apart from avoiding the awkward base" but it doesn't look like that was the case in the patch branch.
05fa819
to
b25e7d2
Compare
@JoostK PTAL |
packages/compiler-cli/ngcc/src/locking/lock_file_with_signal_handlers.ts
Outdated
Show resolved
Hide resolved
The previous implementation mixed up the management of locking a piece of code with the management of writing and removing the lockFile that is used as the flag for which process has locked the code. This change splits these two concepts up, allowing the `LockFile` implementation to be replaced cleanly.
This version of `LockFile` creates an "unlocker" child-process that monitors the main ngcc process and deletes the lock file if it exits unexpectedly. This resolves the issue where the main process could not be killed by pressing Ctrl-C at the terminal. Fixes angular#35761
b25e7d2
to
fd231b9
Compare
Merge-assistance: I am told by the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm - the CI failure is invalid, we should proceed with the merge and fix the infra separately.
The previous implementation mixed up the management of locking a piece of code with the management of writing and removing the lockFile that is used as the flag for which process has locked the code. This change splits these two concepts up, allowing the `LockFile` implementation to be replaced cleanly. PR Close #35934
This PR is now merged into |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
This is a patch version of #35861
It does not include any
AsyncLocker
functionality but otherwise is the same.Probably still needs a review though.