[osg-users] DeleteHandler::_numFramesToRetainObjects

[Robert Osfield]

Hi Anders,

If you need to ensure that DeleteHandler is no longer cashing data,
then you could either let the Viewer destruct then reset the
DeleteHandler or stop the viewer threading then reset the
DeleteHandler.  Setting SingleThreaded will stop all the threads and
do away with the need for the caching. i.e.

   viewer.stopThreading();
   osg::DeleteHander::instance()->setNumFramesToRetainObjects(0);
   osg::DeleteHander::instance()->flushAll();

The Viewer could have the DeleteHandler flush into the destructor, but
this would break apps that have multiple Viewers run at one time so we
have to rely on the above.

Robert

On 8/2/07, Anders Backman <andersb at cs.umu.se> wrote:
> That depends when the osgViewer library is unloaded?
> If that is done during the destructor of a Singleton, then no, there
> is no way of controlling the order in which static singletons are
> deleted, right?
>
> If it is done during the deletion of the osg::Viewer object, then one
> have to keep the scope of the Viewer so that it goes out of scope
> before the shutdown of my singleton...
>
> The reason for all this is that OpenAL does not like to be shutdown
> outside the scope of main() for some reason.
> So I have to do all the deallocation of osgAL inside the scope of
> main() or I will get a crasch inside OpenAL.
>
> /Anders
>
>
> On 8/2/07, Robert Osfield <robert.osfield at gmail.com> wrote:
> > Hi Anders,
> >
> > The DeleteHandler now retains objects for two frames when either
> > DrawThreadPerContext or CullThreadPerCameraDrawThreadPerContext is
> > used to ensure that objects used but not referenced in the draw thread
> > aren't deleted by the main or cull threadeds.
> >
> > When one closes the Viewer one can manually switch off the caching of
> > deleted objects and then flush the DeletaHandler.  In the SVN version
> > of the OSG this is now automatically done when the osgViewer library
> > is unloaded, so perhaps this is enough for your purposes.
> >
> > Robert.
> >
> > On 8/2/07, Anders Backman <andersb at cs.umu.se> wrote:
> > > Hi (again)...
> > >
> > > I just stumbled across another issue with osg2.0 regarding a (new)
> > > policy for reference handling:
> > >
> > > It seems that There is something named _numFramesToRetainObjects in
> > > the default DeleteHandler, which in my case seems to default to 2.
> > > So When a Referenced object is unref():ed and # of ref_ptr:s pointing
> > > to the object, it will still live for another two frames.
> > >
> > > This caused problems in my case, where I wanted to be sure that all
> > > objects are gone before end of main() {} scope.
> > >
> > > What happens now is that during shutdown, some objects are pushed to a
> > > list for later deletion, the scope of main() {} ends, and a atExit()
> > > function is called, executing the actual deletion of the objects.
> > >
> > > Example:
> > >
> > > void main() {
> > > 1.   SingletonManager::init();
> > >
> > >   create objects and register with the SingletonManager()
> > >
> > >   SingletonManager::shutdown(); // delete all registrated objects
> > > within the SingletonManager().
> > >
> > >
> > > }
> > >
> > > // end of main() atExit called which will do the actual deletion of
> > > objects (that should have been deleted by the SingletonManager()
> > >
> > > Which causes problems!
> > >
> > > Now, how to fix this?
> > > One way would be to change the _numFramesToRetainObjects=0, before
> > > calling SingletonManager::shutdown(), but that seems a little bit to
> > > introvert, I don´t really know what happens after the
> > > SingletonManager::shutdown() call, there is a reason for
> > > _numFramesToRetainObjects==2 I guess?
> > >
> > >
> > > The following code WORKS just fine:
> > >
> > > osg::Referenced::getDeleteHandler()->setNumFramesToRetainObjects(0);
> > > SingletonManager::shutdown();
> > >
> > >
> > > The DeleteHandler is common to ALL objects using Referenced, right?
> > >
> > > There must be a better  way of handling this for me?
> > > I would prefer not to put this code into SingletonManager::shutdown()
> > > as it implies that this MUST be the last thing you do, because it
> > > changes the state of the rest of the application...
> > >
> > > Cheers,
> > > Anders
> > >
> > >
> > >
> > > --
> > >
> > >
> > > ________________________________________________________________
> > >  Anders Backman               Email:    andersb at cs.umu.se
> > >  HPC2N/VRlab                  Phone:    +46 (0)90-786 9936
> > >  Umea university              Cellular: +46 (0)70-392 64 67
> > >  S-901 87 UMEA SWEDEN         Fax:      +46 90-786 6126
> > >                                http://www.cs.umu.se/~andersb
> > > _______________________________________________
> > > osg-users mailing list
> > > osg-users at lists.openscenegraph.org
> > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> > >
> > _______________________________________________
> > osg-users mailing list
> > osg-users at lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >
>
>
> --
>
>
> ________________________________________________________________
>  Anders Backman               Email:    andersb at cs.umu.se
>  HPC2N/VRlab                  Phone:    +46 (0)90-786 9936
>  Umea university              Cellular: +46 (0)70-392 64 67
>  S-901 87 UMEA SWEDEN         Fax:      +46 90-786 6126
>                                http://www.cs.umu.se/~andersb
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>