On Mon, Jul 13, 2009 at 12:54 PM, Darin Fisher <[email protected]> wrote:
> On Mon, Jul 13, 2009 at 12:29 PM, Jeremy Orlow <[email protected]>wrote: > >> On Mon, Jul 13, 2009 at 12:20 PM, David Levin <[email protected]> wrote: >> >>> >>> >>> >>> On Mon, Jul 13, 2009 at 8:59 AM, Darin Fisher <[email protected]>wrote: >>> >>>> >>>> WebString exists (has for many moons now). It is just a wrapper for >>>> StringImpl, >>>> the same way WebCore::String is. It is not threadsafe due to the >>>> reference >>>> counting done for StringImpl. >>>> >>> >>> fwiw, I've checked in all the mechanics to do cheaply use StringImpl's >>> across threads. >>> >>> You have to call a method (to be named) and then you'll get back a new >>> StringImpl which uses the *same underlying buffer *and can be passed to >>> another thread. (Right now, webkit code calls StringImpl::copy() for this >>> purpose but that allocates a new buffer and copies the contents there. I >>> can't modify that method due to the fact that it is currently a threadsafe >>> call and that is relied on in some places in webkit.) >>> >>> Let me know if you want/need more details about it. >>> >>> Dave >>> >> >> Would it be better to revisit allowing WebStrings to be transported across >> the IPC barrier (with this new code) or should we go the NullableString16 >> route? I'm now leaning towards the latter because the common case is that >> we _don't_ want to allow null strings. Also it will be similar to string16, >> so it should be more familiar to Chromium developers. Wrapping WebStrings >> might be a bit faster though, since it won't require an additional string >> copy from string16 to and from StringImpl. >> > > > Hmm... > > I'd probably go with NullableString16. If we find the copy overhead to > matter, then we could always optimize later. > > Another issue: Do we want to add conversion methods on WebString? My > first reaction is to try to avoid it... > Hm. I actually thought we should have implicit conversion methods like we do for string16. What's the problem with doing so besides a little bit of bloat? If we're not doing implicit conversion, I'm actually not sure if there's a point to adding NullableString16's since the code will be equally ugly as explicitly having a boolean. J --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
