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

Push root node ref down the tree #1220

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

Push root node ref down the tree #1220

wants to merge 7 commits into from

Conversation

Adlai-Holler
Copy link
Member

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.

@Adlai-Holler
Copy link
Member Author

cc @wiseoldduck @wsdwsd0829

@Adlai-Holler
Copy link
Member Author

The _rootNode ivar is right now only guarded by self->__instanceLock__ but in reality (once we add it) it is ALSO guarded by the root node's lock, since tree modifications are not allowed without the root locked.

@appleguy
Copy link
Member

appleguy commented Nov 7, 2018

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.

...since tree modifications are not allowed without the root locked.

@wiseoldduck
Copy link
Member

So ... the idea here would be to replace yogaRoot and return to the idea of just locking _rootNode to synchronize tree access, probably doing away with lockToRootIfNeeded altogether?

@Adlai-Holler
Copy link
Member Author

@appleguy The public API wouldn't change.

@wiseoldduck Exactly

@TextureGroup TextureGroup deleted a comment Nov 8, 2018
@TextureGroup TextureGroup deleted a comment Nov 8, 2018
@TextureGroup TextureGroup deleted a comment Nov 8, 2018
@TextureGroup TextureGroup deleted a comment Nov 8, 2018
@TextureGroup TextureGroup deleted a comment Nov 8, 2018
return rootLock;
}
}

- (void)_setSupernode:(ASDisplayNode *)newSupernode
Copy link
Contributor

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.

@CLAassistant
Copy link

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

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.

5 participants