On Wed, Jan 9, 2013 at 7:35 PM, Benjamin Poulain <benja...@webkit.org> wrote: > On Wed, Jan 9, 2013 at 7:07 PM, Eric Seidel <e...@webkit.org> wrote: >> On Wed, Jan 9, 2013 at 6:38 PM, Oliver Hunt <oli...@apple.com> wrote: >> > How will we ensure thread safety? Even at just the tokenizing level >> > don't we use AtomicString? AtromicString isn't threadsafe wrt StringImpl >> > IIRC so this seems like it sould add a world of hurt. >> >> AtomicString is already usable from other threads >> (http://trac.webkit.org/changeset/38094), but are correct this is the >> core concern! PickledToken (or whatever it's called) will have to be >> written very carefully in order to minimize/eliminate copies, while >> still guaranteeing thread safety. The correct design and handling of >> PickledToken is the entire question of this whole endeavor. > > That is probably what you meant, but just in case... > > AtomicString can be used from different threads, but is not thread safe. You > must make an isolatedCopy() for message passing if you keep a reference to > the String in your thread. > Not the end of the world, but something to be aware of :)
Yeah, we're aware of this issue. We'll probably end up doing something slightly customized for this use case. For example, many of the AtomicStrings used in parsing are tag and attribute names that are known at compile time (e.g., "div", "href"). When moving these strings back to the main thread, we need only the hash of the string and not the underlying characters in the string (because we know statically that the hash will exist in the main thread's atomic string table). It's tempting to optimize these things prematurely. We'll likely start with a simple approach that makes copies and then optimize away the copies over the development of the feature as indicated by profiles. Adam _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
