ShInitialize/ShFinalize is designed to be called once per process, or it woul...

ShInitialize/ShFinalize is designed to be called once per process, or it would crash at random locations. I changed ShFinalize() to properly cleanup and reset global variables so that they can be called multiple times. I think that the compiler setup is much more complicated than it needs to be. It unnecessarily uses global variables. A custom pool allocator is overkill too.

[Alok Priyadarshi, 2010-05-21 21:12:50]

Vangelis: Could you test if this patch fixes your crash?

[dgkoch, 2010-05-21 21:50:27]

Indexing problem in the destructor. 

Looks good otherwise.

The compiler is also not threadsafe, so if there is any multi-threading going
on, a lock should be used around the compiler usage.

Daniel

http://codereview.appspot.com/1238045/diff/1/2
File src/compiler/ShaderLang.cpp (right):

http://codereview.appspot.com/1238045/diff/1/2#newcode142
src/compiler/ShaderLang.cpp:142: SymbolTables[EShLangCount] = 0;
I suspect you want to use 'i' for an index not EShLangCount.

[Alok Priyadarshi, 2010-05-21 22:02:31]

I think locking PerProcessGPA should be sufficient. Alternatively, we could wrap
these global variables in a struct and return an ShHandle from ShInitialize.

http://codereview.appspot.com/1238045/diff/1/2
File src/compiler/ShaderLang.cpp (right):

http://codereview.appspot.com/1238045/diff/1/2#newcode142
src/compiler/ShaderLang.cpp:142: SymbolTables[EShLangCount] = 0;
oops. Fixed.

[dgkoch, 2010-05-22 00:45:43]

looks good.

[vangelis, 2010-05-22 01:46:42]

Hey, Alok.  I don't seem to be getting the shader compiler crash anymore
either.  Thanks!


On Fri, May 21, 2010 at 5:45 PM, <daniel@transgaming.com> wrote:

> looks good.
>
>
> http://codereview.appspot.com/1238045/show
>