Hi Paul, The .osg plugin is meant to be thread safe and usable in multi-threaded loading. It sounds like initialization is the problem with initGLNames(). I've added a static mutex lock to the initGLNames(), and checked this into svn/trunk. Could you do an svn update and see if the problem still occurs.
If this change works fine I'll roll it into the OSG-2.8 branch as well. Cheers, Robert. On Sun, Jun 21, 2009 at 12:28 AM, Paul Martz<pma...@skew-matrix.com> wrote: > Hi Robert -- In an app I'm working on, I fire off multiple threads to read > multiple files asynchronously (in this case, .OSG files). This seems to work > OK on my dual core Windows laptop, but fails roughly 80% of the time on my > 8-core Mac. The stack trace shows 2 or more threads allocating a std::map > within initGLNames() (osgPlugins/osg/StateSet.cpp). This function does not > appear to be thread-safe; it adds several entries to a static variable > called s_GLNameToGLModeMap. > > Is it a design intent that reading .OSG files must be done serially and not > asynchronously? More generally -- .OSG files aside -- should an app be able > to launch multiple threads to load files asynchronously? > > If reading .OSG files is intended to be a thread-safe operation, I can > prepare a submission. Any thoughts on this would be appreciated, thanks. > -Paul > > _______________________________________________ > 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
