Hi,
On Wed, 2004-05-19 at 02:57, Chad Austin wrote:
> Hi Dirk,
>
> Dirk Reiners wrote:
> > On Wed, 2004-04-28 at 17:34, Chad Austin wrote:
> >
> >>I've wondered about this too... More specifically, I was wondering if
> >>osgInit
> >>and osgExit could be called multiple times in a row, as long as there
> >>is one
> >>exit for each init:
> >>
> >>osgInit(...)
> >> osgInit(...)
> >> ...
> >> osgExit()
> >>osgExit()
> >>
> >>The code didn't look like it could handle that, but it would really
> >>come in
> >>handy... (Ideally, it would be nice if there was no such thing as
> >>osgInit and
> >>osgExit, but it doesn't seem like that's feasible :)
> >
> >
> > No, that's not going to work, init and exit are one-shot things. Where
> > would it come in handy? I can't really imagine what you'd need this for
> > right now. ;)
>
> For an example close to home, the OpenSG Switcher calls osgInit whenever any
> application's apiInit() is called, and osgExit on apiExit(). There was also
> another situation (that I now can't remember) where I wished osgInit() and
> osgExit() could be called multiple times. If some basic refcounting logic
> were
> added, this could become a supported call sequence.
>
> bool atexitRegistered = false;
> int initCount = 0;
>
> osgInit() {
> if (!atexitRegistered) {
> // supports current behavior of osgInit() with no explicit osgExit()
> atexit(function to check initCount and do shutdown)
> }
>
> if (initCount++ == 0) {
> // ...
> }
> }
>
> osgExit() {
> if (--initCount == 0) {
> // ...
> }
> }
>
> COM uses a system like that with CoInitialize() and CoUninitialize().
>
> I wouldn't mind being the one writing the patch and testing if nobody sees
> any
> problems with the above.
>
> > 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.
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 ;-)
regards,
gerrit
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
