Re: [webkit-dev] Strings on multiple threads
On 03.12.2009, at 18:13, Jeremy Orlow wrote: Easier said than done in many cases. For DOM Storage and Databases, there are several classes that are used on multiple threads. And several of these classes contain strings (or contain things that contain strings). It seems very difficult to be absolutely sure these strings are only shared in a safe way unless you make a threadsafeCopy every time you access it. Doing so would probably be negligible performance wise for all the cases I'm looking at, so maybe that's the right answer, but these issues are very subtle. And that's what concerns me most. We should aim to gradually redesign these classes to only use message passing, and generally cleaning up what happens on which thread. It's indeed very difficult to work with strings in this code, but I don't think that's the only problem that arises from using objects on multiple threads there, and it's not necessarily one to tackle in isolation. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Strings on multiple threads
Handling strings on multiple threads is driving me crazy. There are so many subtleties about what's safe and what's not I'm wondering if it makes sense to just make a thread safe class. 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). 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 and that copy might outlive the class, the copy has to be thread safe. 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.) I'm asking here before looking at this seriously since I'm guessing this has come up before and/or there are good reasons why this hasn't been done before. Thanks, J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Strings on multiple threads
Just to be clear, I'm wondering if it makes sense to create a threadsafe string class for use in places that aren't performance intensiveand definitely not a replacement to the current string class. On Thu, Dec 3, 2009 at 5:21 PM, Jeremy Orlow jor...@chromium.org wrote: Handling strings on multiple threads is driving me crazy. There are so many subtleties about what's safe and what's not I'm wondering if it makes sense to just make a thread safe class. 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). 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 and that copy might outlive the class, the copy has to be thread safe. 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.) I'm asking here before looking at this seriously since I'm guessing this has come up before and/or there are good reasons why this hasn't been done before. Thanks, J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Strings on multiple threads
On Thu, Dec 3, 2009 at 5:21 PM, Jeremy Orlow jor...@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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Strings on multiple threads
On Thu, Dec 3, 2009 at 5:46 PM, David Levin le...@chromium.org wrote: On Thu, Dec 3, 2009 at 5:21 PM, Jeremy Orlow jor...@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.) Easier said than done in many cases. For DOM Storage and Databases, there are several classes that are used on multiple threads. And several of these classes contain strings (or contain things that contain strings). It seems very difficult to be absolutely sure these strings are only shared in a safe way unless you make a threadsafeCopy every time you access it. Doing so would probably be negligible performance wise for all the cases I'm looking at, so maybe that's the right answer, but these issues are very subtle. And that's what concerns me most. 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.) Exactlyso we couldn't use StringImpl as is. We could, however, wrap all access to methods that could ref it and/or mutate it with a lock (as an example). I just don't want to have to keep thinking about the subtle threading issues of strings in cases where there's no way it could be performance critical. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
