Bug 195656
| 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 | ||
Ryosuke Niwa
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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Ryosuke Niwa
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.
Fujii Hironori
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().
Ryosuke Niwa
(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.
Geoffrey Garen
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.
Fujii Hironori
*** This bug has been marked as a duplicate of bug 200507 ***