Hi, While tracking down a deadlock issue in osg::GraphicsContext::getCompileContext, I have reached the conclusion that I can't use OSGViewer if I don't use OpenThreads, due to the usage of Thread::CurrentThread() all over the place. Is this assessment correct?
Before I start refactoring OpenThreads to support 'plugging in' existing, externally created threads: Has somebody already done such a thing? Are there any reservations or advice regarding this work? I'm currently investigating if transforming s_contextIDMapMutex into a Mutex (instead of ReentrantMutex) is enough, since it is not used 'reentrantly'. This might take some time due to build system issues on my end, though. Some background: I'm working on an integration of OSG and Equalizer. We use one OSGViewer per GPU rendering thread. The GPU rendering threads are created by Equalizer before the OSGViewer is set up. This works fine as long as there is only one thread, otherwise the whole program deadlocks quickly in: #0 0x91dba922 in semaphore_wait_signal_trap () #1 0x91dc03e6 in pthread_mutex_lock () #2 0x00a4bfcb in OpenThreads::ReentrantMutex::lock () #3 0x00a44817 in osg::GraphicsContext::getCompileContext () #4 0x00db1099 in osgDB::DatabasePager::requiresExternalCompileGLObjects () #5 0x00c94a83 in osgViewer::Renderer::flushAndCompile () #6 0x00c95a38 in osgViewer::Renderer::cull_draw () #7 0x00a475d8 in osg::GraphicsContext::runOperations () #8 0x00ce3e63 in osgViewer::ViewerBase::renderingTraversals () #9 0x00005016 in Channel::frameDraw (this=0x2287200, frameID=219) at Channel.cpp:126 For the curious, the current code can be found in the Equalizer trunk in src/contrib/eqOSG (see signature). Cheers, Stefan. -- http://www.eyescale.ch http://www.equalizergraphics.com http://www.linkedin.com/in/eilemann _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
