mirror of
https://github.com/Swiftgram/Telegram-iOS.git
synced 2025-09-13 15:48:18 +00:00
f7a0ac9760
* Implement mutex ownership and use it to check potential upward lock gathering * Don't hold instance lock and call willEnterHierarchy/didExitHierarchy of ASDisplayNode - This can cause deadlocks (e.g #2605) if subsequent methods, that are implemented by developers, walk up the node tree. - This is a way to keep the optimizations introduced in 9e87813 while making sure the locking situation is a bit safer. * More lock ownership assertions in ASDisplayNode * Document main thread contract of -clearContents * ASNetworkImageNode shoud not call setNeedsPreload while holding instance lock - This helps to avoid potentially deadlocks caused if the node (esp in case it's a subclass of ASNetworkImageNode) walks up the tree in didEnterPreloadState, for example to build logging context. * ASVideoNode should not call setNeedsPreload while holding instance lock - This helps to avoid potentially deadlocks caused if the node (esp. if it's a subclass of ASVideoNode) walks up the tree in didEnterPreloadState, for example to build logging context. * Don't hold instance lock for the entire insert subnode operation - The recursive lock should not be held throughout `_insertSubnode:atSubnodeIndex:sublayerIndex:andRemoveSubnode:`. The method instead should manage the lock itself and acquire it as shortly as possible. The reason is that this method calls many methods outside the scope of `self`. `[subnode __setSupernode:self]` is especially troublesome because it causes the subnode to migrate to new hierarchy and interface states, which triggers `didEnter/Exit(.*)State` methods. These methods are meant to be overriden by subclasses. Thus they might walk up the node tree and potentially cause deadlocks, or they perform expensive tasks and cause the lock to be held for too long. - Other methods that call this method should release the lock before doing so. * Lock getter and setter of `synchronous` flag * Address comment in ASVideoNode * Add main thread assertions to methods that change asset and assetURL of ASVideoNode * Explain CHECK_LOCKING_SAFETY flag * More thread and locking assertions in ASVideNode - It's not safe to call `-[subnode __setSupernode:self]` while holding instance lock of soon-to-be supernode (e.g `self`). - It's also not safe to call `[subnode __setSupernode:nil]` while holding the instance lock of the old supernode (e.g `self`). - did(Enter|Exit)(.*)State methods are always called on main. Add main thread assertions to indicate that. * Minor change in explanation of CHECK_LOCKING_SAFETY flag