Summary:
We observed a deadlock which occurred when two threads were laying out the same set of nodes.
On one thread, layout would occur on a leaf node. It would lock and as part of this layout
process, ASDK walks up the node tree and calls __setNeedsLayout on its supernode until it
reaches the supernode with no supernode. When the supernode gets its call to __setNeedsLayout
it also locks. So leaf node locks and then awaits supernode lock.
On another thread, we're doing a layout pass on the supernode in the above thread. This locks
the supernode and attempts to lock the leaf node. This deadlocks (remember the above thread
is holding onto the leaf lock and awaiting the supernode lock. This thread is holding onto
the supernode lock and awaiting the leaf lock).
This is all exacerbated by the use of recursive locks.
Summary:
Because we trampoline to main when setting _currentImageQuality, there would be situations where displayWillStart was called, we get a cached image and set currentImageQuality to 1.0, and then a background thread calling setDefaultImage would enqueue an operation that sets currentImageQuality to 0 and overwrites the correct value
We move from block based enumeration for the array to fast enumeration as from a benchmark perspective this is faster. For the dictionary we stay with block based enumeration as looking up the value for the key in e.g. fast enumeration would be slower as using the block based API where we get the key and value for passed in
Further information:
- We mark every node as visible in the ASRangeController which NSIndexPath is returned from visibleNodeIndexPathsForRangeController:
- In visibleNodeIndexPathsForRangeController: we get the visible index path's via a call to UITableView's "indexPathsForVisibleRows" method.
- Unfortunately in this case we cannot use indexPathsForVisibleRows to get all the visible index paths as apparently in a grouped UITableView it would return index paths for cells that are just a bit over the edge of the visible area.
- But this edge cells will never get a call for -tableView:cellForRowAtIndexPath:, but we will mark them as visible in the range controller
- In tableView:cellForRowAtIndexPath: we call -configureContentView:forCellNode
- Because we never get a -configureContentView:forCellNode call for the edge cells, the _ASDisplayView of the nodes will never be added to the window and get a willMoveToWindow and didMoveToWindow call and it's never get's added to the window for now and so the node is NOT marked as "in the hirarchy"
- If the deallocation of the views are happening without the UITableView ever scrolled, the cells don't get a call to __exitHierarchy as they were never added to the window and stay in the interface state "visible" and an exception will be raised within the dealloc method of the ASDisplayNode
Calling _updateProgressImageBlockOnDownloaderIfNeeded should be called without _lock held. We will lock super to read our interface state and it's best to avoid acquiring both locks.
appleguy
Garrett Moon
Erekle
Robin Chou
Wendy
Michael Schneider
Hannah Troisi
Eric Jensen