-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Push root node ref down the tree #1220
base: master
Are you sure you want to change the base?
Conversation
The |
Could you say more about this? How will it be enforced, and what would third-party code have to look like? I'm hoping there is a way to ensure that methods like addYogaChild / addSubnode: can be called without the lock and the framework internally manages acquiring the root lock.
|
So ... the idea here would be to replace |
@appleguy The public API wouldn't change. @wiseoldduck Exactly |
return rootLock; | ||
} | ||
} | ||
|
||
- (void)_setSupernode:(ASDisplayNode *)newSupernode |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
YogaTree is different from normal node tree. Meaning when we create a yoga tree, the rootnode will always be self. So even during yoga layout in calculateLayouFromYogaRoot the _rootNode may not be updated timely.
|
Discuss.
Theory is, in the future all tree accesses will require the root lock. We could use a reader/writer mutex if we wanted. This diff uses the instance lock for convenience.
Right now, the down-propagation is murky because tree modifications don't require the root lock, so the ordering there is kind of unclear.
What's nice about this, is you could call a
locked_
method directly on the root node, safely.If we do composite operations on the tree, such as ASM updating, should we hold the root the whole time or separate it, for example? Interesting stuff.