static msclr::auto_gcroot managed variables and the linker lock error

  • Thread starter Thread starter DaTurk
  • Start date Start date
D

DaTurk

Hi,

I've noticed that when trying to create a managed, auto_gcrooted
variable in a antive class, the compiler throws linker exceptions.
While searching some forums I found out that this is a bug? I
couldn't find the work around, just numerous references to the fact
there is one. But apparently there are issues as to how to destroy
said objects. Can anyone shed some more light on this topic for me?
It would be much appreciated.
 
DaTurk said:
Hi,

I've noticed that when trying to create a managed, auto_gcrooted
variable in a antive class, the compiler throws linker exceptions.
While searching some forums I found out that this is a bug? I
couldn't find the work around, just numerous references to the fact
there is one. But apparently there are issues as to how to destroy
said objects. Can anyone shed some more light on this topic for me?
It would be much appreciated.
Click to expand...

It's the "loader lock", not "linker lock" that will bite you with static
native variables in mixed assemblies. Essentially, when static variables
are initialized, the managed runtime typically isn't started yet, so you
can't create managed objects. Destruction has the same issues, static
variables last until the very end, when the managed runtime has typically
shutdown.

I think you might be able to work around with a pointer to gcroot and lazy
initialization. And you'll have to explicitly delete the gcroot object to
get cleanup right.

And don't even think of using a native class instance declared as a global
to perform your init and cleanup, that's the same problem all over again,
although the linker probably wouldn't recognize it.
 
It's the "loader lock", not "linker lock" that will bite you with static
native variables in mixed assemblies. Essentially, when static variables
are initialized, the managed runtime typically isn't started yet, so you
can't create managed objects. Destruction has the same issues, static
variables last until the very end, when the managed runtime has typically
shutdown.

I think you might be able to work around with a pointer to gcroot and lazy
initialization. And you'll have to explicitly delete the gcroot object to
get cleanup right.

And don't even think of using a native class instance declared as a global
to perform your init and cleanup, that's the same problem all over again,
although the linker probably wouldn't recognize it.
Click to expand...

I'm not entirely sure what lazy init is, could you elaborate please?
 
DaTurk said:
I'm not entirely sure what lazy init is, could you elaborate please?
Click to expand...

Just that initialization waits until the first time you use it, maybe
involving a check for NULL. Writing an explicit initialization function
called from a managed type initializer (also called static constructor or
..cctor) also works well.
 
Just that initialization waits until the first time you use it, maybe
involving a check for NULL. Writing an explicit initialization function
called from a managed type initializer (also called static constructor or
.cctor) also works well.- Hide quoted text -

- Show quoted text -
Click to expand...

OK, I understand. But what I don't understand is how this allows me
to use a static, gcrooted, managed variable in native code. I'm not
sure what I'm missing.
 
Back
Top