WIP: Remove eagerness to evaluate extension points.#419
Closed
kitchoi wants to merge 1 commit into
Closed
Conversation
The laziness is relied on. Change events should not be fired until after first access.
kitchoi
commented
Jun 8, 2021
| # fixme: If the extension point has not been accessed then the | ||
| # provider extension registry can't work out what has changed, so it | ||
| # won't fire a changed event. | ||
| self.assertEqual([1, 2, 3, 98, 99, 100], a.x) |
Contributor
Author
There was a problem hiding this comment.
This demonstrates the race condition in this comment:
envisage/envisage/extension_point.py
Lines 186 to 190 in bae1be5
Contributor
Author
|
I should have marked this PR as a draft. Unfortunately, one cannot do so after it has been open (makes sense). |
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
1 participant
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.
This may fix #417
Main change: Remove the call which create the extension list cache early.
Prior to #354, there are a number of FIXME comments in the tests indicating that it was a bug to have to rely on first access of an extension in order for subsequent change events to fire. Creating the cache early resolves those FIXME, but #417 suggests that this is either a bug turned feature, or the FIXMEs then were misguided.
The laziness is relied on. Change events should not be fired until after first access.
As a result, it is possible to run into a race condition, but such a race condition may not matter.
(Not done here: Perhaps the FIXMEs should be changed in light of #417, as they are not actually something need solving.)