Summary: | Add a thread safety assertion for RefCounted | ||
---|---|---|---|
Product: | WebKit | Reporter: | Ryosuke Niwa <rniwa> |
Component: | Web Template Framework | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED DUPLICATE | ||
Severity: | Normal | CC: | achristensen, cdumez, ddkilzer, ggaren, Hironori.Fujii |
Priority: | P2 | ||
Version: | WebKit Nightly Build | ||
Hardware: | Unspecified | ||
OS: | Unspecified |
Description
Ryosuke Niwa
2019-03-12 17:39:25 PDT
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. 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(). (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. 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. *** This bug has been marked as a duplicate of bug 200507 *** |