Hi Cedric, osgViewer/core OSG should already have all the mechanisms available to do clean up of the scene graph and associated OpenGL objects correctly - and in fact it's possibly these existing mechanisms that are causing the failure in question. I suspect the solution will come from studying exactly what is happening and when during the destruction phases of the graphics threads, graphics context, scene graph and viewer, something small is likely amiss - the challenging is pinpointing exactly what this "something small" is...
Once I've progressed the OpenGL ES 2.0 port a bit further I'll revisit this issue, my expectation is that it'll just require a couple of hours of TLC. Robert. On Sun, Oct 11, 2009 at 3:08 PM, Cedric Pinson <[email protected]> wrote: > Hi Robert, > > I think to address the problem but i need to finish other stuff before. > A way i thought to resolve that should be to add to osgViewer a cleanup > method that would release all singleton and data that make it safe to > quit an application. A method like that could be called automatically by > osgViewer destructor or by hand maybe. > It's not clear enough to me how the cleanup could be, but maybe it could > be a way to clean the exit. > > Cheers, > Cedric > > -- > +33 659 598 614 Cedric Pinson mailto:[email protected] > http://www.plopbyte.net > > > On Sun, 2009-10-11 at 07:33 +0100, Robert Osfield wrote: >> Hi Cedric, >> >> As another lead into this problem I've found that the osgcatch example >> now hangs on exit when it's run multi-threaded. All the other >> examples exit fine, but osgcatch hangs inside th new TextureObject >> clean up code at a mutex that seems to be left locked by another >> thread. I don't know why this is, but clearly there is something >> fragile in the clean that will need addressing. >> >> Robert. >> > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
