Non thread-safe container for GraphicsObjectManager's

[Dmitriy]

Simple example:

Set the ThreadingModel of the Viewer to CullDrawThreadPerContext. This will cause update traversal to be performed on a separate thread from render.
Next, we write an updateCallback that creates geometry so that we can then transfer it to rendering (of course, using thread synchronization).
Suppose some geometry becomes obsolete before it's submitted for rendering and removed in our updateCallback. And this geometry contained the program.

Result:

Removing the program will add a new element to the _managerMap container(GLProgramManager). It will happen in one thread.
At this time, the render thread executes ContextData::newFrame. There, the elements of the _managerMap container are iterated.
As a result, we get a crash.

[Robert Osfield]

Sounds like your are misusing the OSG and provoking a race condition because of it.

The OSG is designed to handling multi-thread creation and deletion of scene graph, there is the DatabasePager and PagedLOD classes designed specifically for this purpose. It sounds like you are trying to replicate this. If you can I would recommend using these.

The OSG is also designed that the update traversals/callbacks don't operate on elements of the scene graph that are being still being rendered, there is mechanisms in place to prevent updates happening premature by holding the next frame back till all dynamic objects are rendered. I presume you are also not leveraging this. It's so long since I've used the OSG I can't recall the specifics off the top of my head.

I'm closing this Issue as it looks like using the OSG in a way that is intended to be supported. The problem likely resides in the application side assumptions.