Skip to content
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

WIP: Remove eagerness to evaluate extension points. #419

Closed
wants to merge 1 commit into from

Conversation

kitchoi
Copy link
Contributor

@kitchoi kitchoi commented Jun 8, 2021

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.)

The laziness is relied on. Change events should not be fired until after first access.
# 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)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This demonstrates the race condition in this comment:

# In case the cache was created first and the registry is then mutated
# before this ``connect`` is called, the internal cache would be in
# an inconsistent state. This also has the side-effect of firing
# another change event, hence allowing future changes to be observed
# without having to access the trait first.

@kitchoi
Copy link
Contributor Author

kitchoi commented Jun 8, 2021

I should have marked this PR as a draft. Unfortunately, one cannot do so after it has been open (makes sense).
As I cannot commit to following this through, I will close this PR shortly to avoid blocking future changes.

@kitchoi kitchoi closed this Jun 8, 2021
@kitchoi kitchoi deleted the revert-fixme branch June 8, 2021 18:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Extension point resolution too eager in Envisage 6.0.0
1 participant