Hi Pjotr, On 6 November 2014 12:52, Pjotr Svetachov <pjotrsvetac...@gmail.com> wrote:
> I'm still in the process of compiling, but I had a look at the code. > As I understand it an object is put in the registery cache by > Registry::instance()->readNode(), thats before > FindCompileableGLObjectsVisitor will traverse it. This means that you will > get race conditions in FindCompileableGLObjectsVisitor trying to set/get > markerobjects. Also get/setUserdata is not thread safe also. > Ouch, I didn't consider this possibility. To address this we'd need to delay registration of the loaded objects with the cache till after the post processing has been done - this would avoid other issues about the subgraph being loaded and post processed in a multi-threaded way. > Another problem can arise when people add their own userdata inside an > object after they load it or have objects that have userdata already > present file. > I have considered this possibility, but wanted first to get a solution down and tested before generalizing if need be. One possibility would be to only ever do the compile when UserData is completely empty rather than just matched, which would mean less subgraphs might be no pre-compiled but this is a safer outcome than a race conditions. The other approach would be see if UserDataContainer is attached as UserData and then store the MarkerObject within the UserDataContainer. If possible I want to avoid forcing the creating of a UserDataContainer per compilable object though, which is why I directly assigned the MarkerObject as UserData as this object is shared between all compiled objects it's effective memory overhead is zero. Another possible approach is to add a flag to StateAttriibute/Drawable so signify that it's been processed and shouldn't be touched again. This would however add an extra memory variable to these classes just for this particular usage model. I should add that I consider the user of the object cache and use of user assigned data to be niche activity, most users won't utilize this facility, so the cost of supporting this particular usage combination should not push an overhead into the core OSG. Robert.
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
