-
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
[ASImageNode] Fix a threading issue which can cause a display completion block to never be executed #1148
[ASImageNode] Fix a threading issue which can cause a display completion block to never be executed #1148
Conversation
nguyenhuy
commented
Sep 28, 2018
•
edited
Loading
edited
- Clear _displayCompletionBlock while we still have the node's instance lock. Because it may not be the same block by the time the lock is reacquired. In other words, it can happen that another thread sets a new display block after this thread releases the lock but before it reacquires it. And we don't want to clear out the new block.
- Reduce a lock/unlock pair which should help perf a tiny bit.
eda62ab
to
aa9e796
Compare
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.
LGTM
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.
Feel free to merge this, nice fix! Comments are non-blocking / optional observations.
if (shouldPerformDisplayCompletionBlock) { | ||
_displayCompletionBlock = nil; | ||
} | ||
|
||
BOOL hasDebugLabel = (_debugLabelNode != nil); |
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.
Since many of the calls in the debug label section require the lock anyway (like self.bounds), should we just continue holding the lock until after that?
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.
There's a comment below stating that we don't care about locking in the debug section. I don't remember the reasoning behind that (locking violation somehow?), but let's revisit it in another PR.
CHANGELOG.md
Outdated
@@ -57,6 +57,7 @@ | |||
- Clean up timing of layout tree flattening/ copying of unflattened tree for Weaver. [Michael Zuccarino](https://github.com/mikezucc) [#1157](https://github.com/TextureGroup/Texture/pull/1157) | |||
- Fix crash setting attributed text on multiple threads [Michael Schneider](https://github.com/maicki) | |||
- [ASTextNode2] Ignore certain text alignments while calculating intrinsic size [Huy Nguyen](https://github.com/nguyenhuy) [#1166](https://github.com/TextureGroup/Texture/pull/1166) | |||
- [ASImageNode] Fix a threading issue which can cause a display completion block to never be executed. [Huy Nguyen](https://github.com/nguyenhuy) [#1148](https://github.com/TextureGroup/Texture/pull/1148) |
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.
From the header file, it isn't too clear that calling the method multiple times will overwrite the previous block without calling it. In order to guarantee balanced calls, we'd probably need to track them with an array.
This seems like an increasingly common case in the framework (even interfaceStateDelegates now), so it might be worth creating a helper class like ASBlockList / ASBlockQueue to manage efficiently. Not important right now, just an idea.
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.
Agree that it'd be nice to have track all blocks in an array.
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.
Nice!
3494455
to
ce4bb1c
Compare
…ode's instance lock - Because it may not be the same block by the time the lock is reacquired. In other words, it can happen that another thread sets a new display block after this thread releases the lock but before it reacquires it. And we don't want to clear out the new block. - Reduce a lock/unlock pair which should help perf a tiny bit.
ce4bb1c
to
3a35a9a
Compare
🚫 CI failed with log |
🚫 CI failed with log |
Generated by 🚫 Danger |
…tion block to never be executed (TextureGroup#1148) - Clear _displayCompletionBlock while we still have the node's instance lock. Because it may not be the same block by the time the lock is reacquired. In other words, it can happen that another thread sets a new display block after this thread releases the lock but before it reacquires it. And we don't want to clear out the new block. - Reduce a lock/unlock pair which should help perf a tiny bit.