195656 2019-03-12 17:39:25 -0700 Add a thread safety assertion for RefCounted 2019-10-23 22:56:54 -0700 1 1 1 Unclassified WebKit Web Template Framework WebKit Nightly Build Unspecified Unspecified RESOLVED DUPLICATE 200507 P2 Normal --- 1 rniwa webkit-unassigned achristensen cdumez ddkilzer fujii ggaren oldest_to_newest 1515787 0 rniwa 2019-03-12 17:39:25 -0700 I think we should add some thread safety check for RefCounted. Namely, we should avoid creating an object and ref / deref it in two different threads. Such objects should be using ThreadSafeRefCounted instead. 1515789 1 rniwa 2019-03-12 17:40:33 -0700 Note that it's technically correct to create an object in one thread, pass it to another thread if the new thread has an exclusive ownership / access right. However, such a code is error prone so I'd argue that we shouldn't have such a code without such code using ThreadSafeRefCounted instead. 1515830 2 fujii 2019-03-12 19:28:17 -0700 WTF::String has a non-atomic ref couter, but it is a quite common pattern to pass a WTF::String cross-threads by using isolatedCopy(). 1515831 3 rniwa 2019-03-12 19:31:37 -0700 (In reply to Fujii Hironori from comment #2) > WTF::String has a non-atomic ref couter, but it is a quite common pattern to > pass a WTF::String cross-threads by using isolatedCopy(). That's a good point. Maybe we need to allow this usage in some classes, or perhaps isolatedCopy needs some magic to unset the thread identity. 1516034 4 ggaren 2019-03-13 10:41:05 -0700 We used to have assertions like this and we had to remove them. The corner case was JavaScriptCore. JavaScriptCore allows clients to run on any thread, and it ensures thread safety through coarse-grained locking. JavaScriptCore also uses many fundamental WTF types. We could not find a practical way to annotate all types as asserting their thread affinity if and only if not used by JavaScriptCore. But perhaps the opposite is possible: WebCore could annotate certain important objects upon allocation as being tied to a thread. 1583240 5 fujii 2019-10-23 22:56:54 -0700 *** This bug has been marked as a duplicate of bug 200507 ***