[webkit-dev] Strings on multiple threads

[David Levin]

On Thu, Dec 3, 2009 at 5:21 PM, Jeremy Orlow <jorlow at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091203/6c04a8c9/attachment.html>