[webkit-dev] Atomic Strings and static vars

Mike Emmel mike.emmel at gmail.com
Mon Jun 5 12:14:25 PDT 2006

On 6/5/06, Darin Adler <darin at apple.com> wrote:
> On Jun 5, 2006, at 7:49 AM, Geoffrey Garen wrote:
> > FYI, a static AtomicString would be a Bad Thing (TM) anyway, since
> > it would require WebKit to have a static initialization routine for
> > that string. Such a routine increases the start-up time and memory
> > footprint of anything that links against WebKit, which includes
> > just about everything that ships with OS X. (In fact, we have some
> > open bugs about that.)
> You can use a static AtomicString inside a function. These types of
> global variables are initialized the first time the function is called.
> As Geoff says, because of requirements for the WebKit framework on OS
> X, global variables outside functions with constructors are not
> allowed in JavaScriptCore, WebCore, or WebKit. That's why you'll see
> a lot of globals with, say, a HashMap* type instead of just a HashMap.
>      -- Darin
Not disagreeing but the problem with global statics is technical and
has to do with the order or lack thereof of the static constructors.
In this case one is missing and in anycase 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 this probably means using a different
static initializer on another class.

The choice to use lazy initialization vs immediate is a different
issue but globals should not be prevented by what seems to be a
technical bug. I happen to agree with the lazy approach in this case I
was thinking I'd use the same string in multiple places therfore the
global turned out I did not need too so no biggie. But agian this does
not mean the current implementation is correct.


More information about the webkit-dev mailing list