On Mon, Jul 13, 2009 at 12:59 PM, Jeremy Orlow <[email protected]> wrote:
> 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 > Yeah, that's a good point. Implicit conversion methods it is then. -Darin --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
