On Thu, Dec 3, 2009 at 5:21 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
Handling strings on multiple threads is driving me crazy.
My recommendation don't use strings on multiple threads. If you do, it has a high chance of being wrong because it is very subtle so try not to do it. Instead creating a string for another thread is using crossThreadString which is relatively cheap (sorry about the name, I have a bug on fixing that just haven't had time to think of something better). (Note that method isn't threadsafe.)
For example, String1 + String2 is not safe if either of those threads is from another thread (since if either string is empty, it'll just point to the other strings StringImpl).
See above : don't do it :)
Another example: if you have a class that isn't always destroyed on the same thread and anything is making a copy of a string it owns
Don't hand out strings from such a class. Only hand out strings that come from the crossThreadString method or the copy method. Or only give out a UChar*. (Of course, it would be nice if you could make your class always be destroyed on the same thread or at least destroy all of its strings on the same thread where they were used.) I understand that making all strings ThreadSafeShared is completely out of
the question, but maybe we can make another class of strings that is safe? Maybe we can even do it in a way that still shares the majority of the existing string code? (Ideally without resorting to templates.)
Or is there a way to change your code to not use the same string class on multiple threads? A big issue is the RefCounted base for StringImpl. (Next you'd also have problems with append, insert, etc.) dave