[webkit-dev] Atomic Strings and static vars

[Mike Emmel]

Well I finally looked into the file I was going to create the patch
and what do I find in AtomicString.cpp


#include "config.h"

#if AVOID_STATIC_CONSTRUCTORS
#define ATOMICSTRING_HIDE_GLOBALS 1
#endif


So someone thought it should be optional.
Of course as I pointed out earlier AtomicString is broken so changing this
ifdef will break the build.

Mike




On 6/5/06, Mike Emmel <mike.emmel at gmail.com> wrote:
> 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
> >
> >
>