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

Fix: frame dependency calculation #76

Merged
merged 6 commits into from
Jun 8, 2022
Merged

Fix: frame dependency calculation #76

merged 6 commits into from
Jun 8, 2022

Conversation

kalzoo
Copy link
Contributor

@kalzoo kalzoo commented Jun 2, 2022

Another fix, back to back with #73.

Closes #75

This takes the approach of tracking the instructions which use and block a frame separately, solving the problems described in #75. It's more complex, but should still remain readable and maintainable. This PR includes a couple more snapshot test cases to illustrate the differences and prevent regression.

@kalzoo kalzoo self-assigned this Jun 2, 2022
@genos
Copy link
Contributor

genos commented Jun 2, 2022

Issue-linking-wise, @kalzoo, is this aimed at #75?

Copy link
Contributor

@genos genos left a comment

Choose a reason for hiding this comment

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

Some requests for shorter code 🏌️, a suggestion about changing the return type of a function, but otherwise LGTM

src/program/graph.rs Show resolved Hide resolved
src/program/graph.rs Outdated Show resolved Hide resolved
src/program/graph.rs Outdated Show resolved Hide resolved
src/program/graph.rs Outdated Show resolved Hide resolved
src/program/graph.rs Outdated Show resolved Hide resolved
///
/// If the frame is currently blocked by other nodes, it will add itself to the list of blockers,
/// much like a reader in a read-write lock.
pub fn register_blocker(&mut self, node: ScheduledGraphNode) -> Option<ScheduledGraphNode> {
Copy link
Contributor

Choose a reason for hiding this comment

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

I can't think of a better name, so maybe ignore this, but I think a more suggestive function name that says something about returning self.using might be helpful.

I suppose I have a similar (-ly unhelpful) note for register_user's naming, too.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Changed - what do you think?

Copy link
Contributor

Choose a reason for hiding this comment

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

👍

@kalzoo
Copy link
Contributor Author

kalzoo commented Jun 2, 2022

Issue-linking-wise, @kalzoo, is this aimed at #75?

You bet, fixed description

@kalzoo
Copy link
Contributor Author

kalzoo commented Jun 2, 2022

Note: this fails the example cited in this issue; if the spec remains unchanged, this will have to be modified.

Copy link
Contributor

@notmgsk notmgsk left a comment

Choose a reason for hiding this comment

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

Nice. Took me a hot minute to understand the logic, but that might be because I've been awake since 5AM. Only question is: do the PreviousNodes methods need to be public?

src/program/graph.rs Outdated Show resolved Hide resolved
@kalzoo kalzoo merged commit ee0e406 into main Jun 8, 2022
@kalzoo kalzoo deleted the 75-frame-dependencies branch June 8, 2022 18:41
@github-actions
Copy link

github-actions bot commented Jun 8, 2022

🎉 This PR is included in version 0.11.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Bug in Timing/Frame Dependencies
3 participants