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 two race conditions in RecyclerBinder. #917

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

jaceksur
Copy link

Summary

If the collection has not completed initial layout by the time onNewWorkingRange() is called, it will short circuit and not be called again.

If a collection item has not completed initial layout by the time we attempt to check if it belongs to a working range, the call noop-s and is not attempted again.

In each case, save the working range and apply it when the layout completes.

Changelog

Fix two race conditions in RecyclerBinder.

Test Plan

Want to get feedback on my approach first.

If the collection has not completed initial layout by the time onNewWorkingRange() is called, it will short circuit and not be called again.

If a collection item has not completed initial layout by the time we attempt to check if it belongs to a working range, the call noop-s and is not attempted again.

In each case, save the working range and apply it when the layout completes.
Fix two race conditions in RecyclerBinder.
@adityasharat
Copy link
Contributor

adityasharat commented Nov 15, 2022

Thank you for contributing 😃
You'll have to accept the CLA for us to import this PR

@jaceksur
Copy link
Author

Done!

@facebook-github-bot
Copy link
Contributor

@pentiumao has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

@facebook facebook deleted a comment from facebook-github-bot Dec 2, 2022
@@ -2689,6 +2713,15 @@ private synchronized void commitResolutionResult(
if (mTreeState != null) {
mTreeState.unregisterRenderState(resolutionResult.treeState);
}

WorkingRangeAndPositionHolder workingRangeAndPosition = null;
synchronized (this) {
Copy link
Contributor

Choose a reason for hiding this comment

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

This lock seems unnecessary, because commitResolutionResult is synchronized. Can we remove it?

@@ -116,6 +118,9 @@ interface ComponentTreeMeasureListenerFactory {
@GuardedBy("this")
private int mLastRequestedHeightSpec = UNINITIALIZED;

@GuardedBy("this")
private WorkingRangeAndPositionHolder mPendingWorkingRangeAndPosition = null;
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we add @nullable to this field to make it Nullsafe?

@@ -221,6 +223,8 @@ public void run() {
private final RunnableHandler mPreallocateMountContentHandler;
private final boolean mPreallocatePerMountSpec;

private @Nullable WorkingRangeHolder mPendingWorkingRange;
Copy link
Contributor

Choose a reason for hiding this comment

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

This private field is never accessed, can you clarify its purpose? Thanks!

lastFullyVisibleIndex)));
}

synchronized void checkWorkingRangeAndDispatch(
Copy link
Contributor

@pentiumao pentiumao Dec 7, 2022

Choose a reason for hiding this comment

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

It seems like we broke a test case due to this change, can we fix it? Thanks.

I think we should override this method for TestComponentTreeHolder as well like this.

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

Successfully merging this pull request may close these issues.

4 participants