[webkit-dev] Atomic Strings and static vars

[Mike Emmel]

On 6/5/06, Darin Adler <darin at apple.com> wrote:
> On Jun 5, 2006, at 12:14 PM, Mike Emmel wrote:
>
> > the problem with global statics is technical and has to do with the
> > order or lack thereof of the static constructors
>
> I'm not sure what you mean.
>
> For our frameworks for Mac OS X we have a constraint for performance
> reasons, entirely separate from the static initialization order
> issue. Because of that constraint, the WebKit project rule is "no
> static initialization at all".
>
No problem.

> Yes, there are some technical issues about doing global static
> initialization right. But in this project we avoid them since we
> don't have any for the above reason.
>
> > In this case one is missing and in any case order is never assured
> > technically the static constructor may be on the wrong class. My
> > opinion is you may want to fix the core classes to actually work
> > correctly with global statics
>
> I don't think we want to do this, again for performance reasons.
>
> We don't want to pay for a global variable fetch and a branch when
> creating each AtomicString to check to see if the global
> initialization has been done yet. Instead, we have chosen the
> approach of not using AtomicString until after the AtomicString::init
> () function is called.
>
By moving the static variable to be lazy you have ensured this.
My point is that at least for gcc you can use static constructors to initialize
AtomicString::init could be called from one of those.

Agian I have no problem with all the reasons given to not  make heavy
use global static atomic string.
I would argue that the reasons may not be valid for all possible ports
of WebKit.
If some one had a valid reason then it would at least intially  be
port specific.

I think its a bug in the implementation that atomic string cannot be
used for static variables
regardless of  OSX and the use cases on osx. If its fixed the patch
could even be ifdef'ed to not function on OSX to prevent static
variable from sneaking into generic code.

I don't like basic stuff like AtomicString being broken its not a good thing.
There is nothing wrong with making it work correctly andd efficiently
in the case of
global static variables and also nothing wrong with ifdefing that
support so its not on by default. Later if there is a either port
specific or real generic need the support can be turned on.

I guess I'm a bit surprised your willing to leave a basic class like
AtomicString broken because of current design decisions event if there
often (not always) correct. At the very least add a comment to the
header.

Its tough to wager on a email list but I promise to buy and extra ipod
if this is not fixed
within the next two years. I don't see me loosing that bet :)

Mike




>      -- Darin
>
>