[GitHub] incubator-weex issue #1072: [WEEX-249][iOS]fix WXRuleManager multi-thread cr...
Github user acton393 commented on the issue: https://github.com/apache/incubator-weex/pull/1072 @xuyouyang Cases occurs to me that one of thread operating the storage and then operating the fontFamilyDic, as they was in a same dictionary. And for `os_unfair_lock`, this is not a type of recursive lock, so it can not be acquired multi times. ---
[GitHub] incubator-weex issue #1072: [WEEX-249][iOS]fix WXRuleManager multi-thread cr...
Github user xuyouyang commented on the issue: https://github.com/apache/incubator-weex/pull/1072 hi @acton393 if we change fontFamilyDic type to NSMutableDictionaryï¼will it also cause multi-thread problem? For example, other thread operate object in fontFamilyDic. And I have a doubt that why WXThreadSafeDictionary can be a deadlock? It created in different queue and different lock. ---
[GitHub] incubator-weex issue #1072: [WEEX-249][iOS]fix WXRuleManager multi-thread cr...
Github user acton393 commented on the issue: https://github.com/apache/incubator-weex/pull/1072 hi @xuyouyang thank you for your contribution, sure that's a bug, you are very careful. and we can change the variable type in WXUtility.m or change the type during its creation to fix it. I found that `fontFamilyDic` is a second dictionary which is a object in `fontStorage` which is also `WXThreadSafeDictionary` and its key is 'fontFamily', I'm concerning about that if we change the `fontFamilyDic` type to `WXThreadSafeDictionary`, there can be a deadlock as `WXThreadSafeDictionary` using lock to ensure its thread-safe. so I think we can fix it by changing type in `WXUtility.m`. ---
[GitHub] incubator-weex issue #1072: [WEEX-249][iOS]fix WXRuleManager multi-thread cr...
Github user weex-bot commented on the issue: https://github.com/apache/incubator-weex/pull/1072 Messages :book: has no jsfm file changed. :book: jsfm test finished. Generated by :no_entry_sign: http://github.com/danger/danger-js/";>dangerJS ---