Remove the require lock on LoadError#7074
Merged
headius merged 1 commit intojruby:jruby-9.3from Feb 8, 2022
Merged
Conversation
LoadError should be treated as a completed load for locking locking purposes, since it means an attempt was made to load the file and that load completed with an error condition. This appears to be different than the behavior for other errors that are raised which should leave the require as being in-progress.
b3da014 to
822f6ff
Compare
Member
Author
|
Specs did not like the first attempt here to clear locks no matter what! When an error is raised from a loading file, we should allow any other concurrent require to proceed in its attempt to load the file. The LoadError case should clear the lock so that the file does not appear to have successfully loaded. This logic around the lock may need some extra bits, like detecting if there are others waiting on this require. I believe the cases are as follows:
|
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.
Leaving this lock in place indicates to later feature tests that
the file was never loaded, incorrectly causing autoload constant
lookups to fail to load the file a second time. Instead, we
always remove any lock set up for the require so the feature does
not look like it is still in the process of loading.
See #7070
This is a WIP and we will see how it handles tests. I believe I originally added the
destroyLocklogic to form fit behavior to some spec, but I cannot remember which spec behavior led me to doing this. It seems wrong now to leave the lock in place under any circumstances, since it will interfere with future attempts to load that file (the case in #7070).