Hi Robert,
Hm, there is probably something I don't see. I am new to the code...
I assumed that a TerrainTile cannot be _completely_ deleted in the
Terrain::update call, because if it were it _must_ have passed through
Terrain::unregisterTile and then it wouldn't be in the update set to begin
with. Therefore it is still safe to investigate the raw pointers in the
_updateTerrainTileSet in Terrain::update.
Do you agree on the assumption? If not can you exemplify when it doesn't
hold?
Cheers,
Ola
On Mon, 27 Aug 2012 15:49:47 +0200, Robert Osfield
<robert.osfi...@gmail.com> wrote:
Hi Ola,
I don't think your suggested change will help as you are taking a
reference to a potentially deleted object, the Terrain::_mutex that is
locked doesn't effected the children just the management of the
Terrain::_terrainTileMap and _updateTerrainTileSet.
My current thought is that we'll need to introduce a form of set that
manages a list of observer_ptr<> much in the same way that the
ObserverNodePath is managed, so we'll need an equivalent
ObserverNodeSet class.
Robert.
On 27 August 2012 12:46, Ola Nilsson <o...@weatherone.tv> wrote:
Hi Robert et al.,
I finally got the time to investigate the code (osgTerrain/Terrain.cpp).
As I see it, it is not necessary to introduce a new data structure to
hold
the list of update tiles. The issue was that a TerrainTile could be
partly
destructed but not unregisterTile:ed, when an Terrain::update call was
made.
Then, a TerrainTile could get its refcount bumped while being
destructed and
be deleted with a dangling ref_ptr to deleted memory.
My solution is inspired by the code in ObserverSet::addRefLock and only
modifies Terrain::traverse. I bump the raw Terrain-pointers in the
update
list to ref_ptr and check their status before doing any work on them.
TerrainTiles with a refcount of 1 should be discarded (but not deleted).
I have attached the complete file. Should this conversation be
continued at
osg-submissions also/instead?
Cheers,
Ola
Hi Ola et. al,
I've looked at the problem Terrain containers and they present an
interesting issue - the std::set<TerrainTile*> that is used can't
easily be converted into an std::set< osg::observer_ptr<TerrainTile> >
as the observer_ptr<> can have it's value changed to NULL by another
thread when destructing the observed TerrainTile and std::set<>
require their values to be const.
What will be required is a custom container of osg::oberserver_ptr<>
along the lines of osg::OberservedNodePath but written to manage it's
contents in a similar way to a std::set.
Robert.
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
