Re: [Opensg-users] osgInit and osgExit cycles in same app

[Chad A. <ae...@vr...>]

Gerrit Voss wrote:
> On Wed, 2004-05-19 at 02:57, Chad Austin wrote:
>>Dirk Reiners wrote:
>>>And unless we get more influence on the startup sequence of C++, we will
>>>need osgInit. The primary use is to call the initialize functions of the
>>>type system. Given that we store the complete list of fields in each
>>>type, all the base types have to be initialized before that, and the
>>>undefined initialization order f static C++ instances makes that a
>>>little hard. Exit is probably not as critical, but init is hard to get
>>>around.
>>
>>Fair enough.
> 
> 
> I would not call it hard, as the standard specifically says this is 
> implementation dependent it is really impossible ;-), I tried messing
> with the startup symbols but this is not much fun either ;-).
> 
> Anyway I would be more interested  what would you expect osgExit to do,
> as osgInit is going to be split up anyway to allow runtime loading of 
> shared libs, getting multiple calls into this should be possible. So
> far osgExit (in theory) shuts down the type system and the MT stuff but
> does not touch anything else. I really don't want to imaging what might
> happen if we terminate the type and MT stuff with running threads and
> fieldcontainers around, or would you want to have osgExit to delete
> those too (my guess). Alternatively we could terminate the osgExit
> call if there are still OSG structures present. 

I'm not totally sure what you're asking...  but you'd pretty much have to say 
that calling (the last) osgExit while OpenSG is still working would result in 
undefined behavior.  If you could warn or give an error message in osgExit if 
OpenSG objects still existed, that could certainly help OpenSG users find leaks.  :)

> Your example above looks slightly easier to solve as you have nested
> calls, but in general I would like to look at the more general 
> problem first ;-)

Makes sense.