Push root node ref down the tree - #1220
Adlai-Holler wants to merge 7 commits into
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 |
| } | ||
| } | ||
|
|
||
| - (void)_setSupernode:(ASDisplayNode *)newSupernode |
There was a problem hiding this comment.
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.