Hi Umit, I'm not familiar with MFC nor the osgviewerMFC example, so my guess is that there is some issue with it. viewer.stopThreading() will stop all the threading that the viewer itself starts. If you have other threads running then this is down to your app to handle them.
As for the errors on exit, this could be due to a number of things. Without stack traces and knowledge of osgviewerMFC/MFC I can't make any clear suggestion. As a general note threading and clean up of graphics context are the items that one has to be careful of. Robert. On Fri, Feb 13, 2009 at 2:03 PM, Ümit Uzun <umituzu...@gmail.com> wrote: > Hi Robert, > > I have known stopping viewer but I actually asked about static render > running thread, and how should I stop it and order of stopping mechanism. > For example I have tried much of below codes combinations but always I get > error while shutting down the application. > > _viewer->setDone(TRUE); > Sleep(1000); > _viewer->stopThreading(); > Sleep(1000); > _endthread(); > > Firstly I should setDone to TRUE and then stop viewer threading and lastly > I end the created thread for static render function. But it always give me > error while trying to do all these operaion in destructor. But while I > delete different place out of destructor, it is closing error-free. > > I mean if I delete the created object explicitly there is no problem, but if > I delete the created object in destructor there is threading problem. > > Thanks so much. Regards. > > 2009/2/13 Robert Osfield <robert.osfi...@gmail.com> >> >> Hi Umit, >> >> The viewer.stopThreading() method will stop the threads and not return >> until all threads have been stopped. >> >> Robert. >> >> On Fri, Feb 13, 2009 at 6:51 AM, Ümit Uzun <umituzu...@gmail.com> wrote: >> > Hi Brad, >> > >> > Could you give more explanation please? How can you be sure the thread >> > was >> > stopped and in which method? >> > >> > Regards. >> > >> > 2009/2/13 Brad Huber <br...@procerusuav.com> >> >> >> >> FYI, >> >> >> >> >> >> >> >> We spent some time debugging this and found the problem. >> >> >> >> >> >> >> >> I was making the unfortunate mistake of stopping the osg threads in a >> >> deconstructor which was called AFTER destroying the window. Apparently >> >> OSG >> >> does not gracefully shut down threads and such if the window is pulled >> >> out >> >> from under it. >> >> >> >> >> >> >> >> The fix was to make sure that stopping threading and shutting down the >> >> viewer was all down BEFORE the window was made invalid. >> >> >> >> >> >> >> >> Hope this helps someone else. >> >> >> >> >> >> >> >> Thanks >> >> >> >> -Brad >> >> >> >> >> >> >> >> From: osg-users-boun...@lists.openscenegraph.org >> >> [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ümit >> >> Uzun >> >> Sent: Thursday, February 12, 2009 3:35 AM >> >> To: OpenSceneGraph Users >> >> Subject: Re: [osg-users] OSG Multithreaded Viewer and Windows/MFC >> >> problem >> >> >> >> >> >> >> >> Hi Brad, >> >> >> >> I have same problem , but I can't resolve exactly. I only find kludge >> >> :) >> >> How can you delete your class which contains "static render" function? >> >> If >> >> you delete this class in destructor, it's normal getting error while >> >> closing >> >> your application. I have tried almost a day to resolve this undefined >> >> problem but couldn't. >> >> >> >> And My solution is; deleting class before parent destructor calling. I >> >> mean, you have renderClass and mainClass. >> >> renderClass is which contains all rendering operation and static render >> >> function. >> >> You create renderClass object from mainClass and before closing >> >> application you should delete renderClass out of mainClass destructor. >> >> And >> >> after that you should let the mainClass destructor to run. I hope it >> >> will >> >> give you smooth and error-free closing :) >> >> >> >> Regards. >> >> >> >> 2009/2/12 Brad Huber <br...@procerusuav.com> >> >> >> >> Hello, >> >> >> >> >> >> >> >> I am currently struggling with a problem that is manifesting in our MFC >> >> based app when using MultiThreading model with osg viewer. >> >> >> >> >> >> >> >> First of all when setting up the viewer in my class I used: >> >> >> >> >> >> >> >> >> >> >> >> mViewer->setThreadingModel(osgViewer::ViewerBase::ThreadingModel::AutomaticSelection); >> >> >> >> I also tried the default of not setting anything and the same problem >> >> happens. If I set it to single threaded the problem disappears but >> >> obviously I don't want to run single threaded. >> >> >> >> >> >> >> >> Everything seems to run fine and then when I close the app my class >> >> destructor gets called. The only code in the destructor is: >> >> >> >> mViewer->setDone(true); >> >> >> >> Sleep(1000); >> >> >> >> mViewer->stopThreading(); >> >> >> >> Sleep(1000); >> >> >> >> >> >> >> >> Which is the same as what the example mfc code in the repository does. >> >> The sleeps were only added to see if there was a race condition >> >> problem. >> >> >> >> >> >> >> >> However when I trace in to stopThreading I see that it returns >> >> immediately >> >> on the first line: >> >> >> >> if (!_threadsRunning) return; >> >> >> >> >> >> >> >> As a result it doesn't kill any threads or anything else BUT there are >> >> threads still running and they show up in the debugger. >> >> >> >> >> >> >> >> Then as the app continues to close I get: >> >> >> >> >> >> >> >> >> >> >> >> Which takes me to: >> >> >> >> win32mutex.cpp line 111 >> >> >> >> int Mutex::lock() { >> >> >> >> Win32MutexPrivateData *pd = >> >> >> >> static_cast<Win32MutexPrivateData*>(_prvData); >> >> >> >> >> >> >> >> #ifdef USE_CRITICAL_SECTION >> >> >> >> >> >> >> >> // Block until we can take this lock. >> >> >> >> EnterCriticalSection( &(pd->_cs) ); ß exception here! >> >> >> >> >> >> >> >> return 0; >> >> >> >> >> >> >> >> #else >> >> >> >> … >> >> >> >> >> >> >> >> This is OSG/Openthreads stuff! I look up the call stack and see the >> >> osgViewer::Renderer. >> >> >> >> >> >> >> >> >> >> >> >> Does anyone have any insights about why this is going on? >> >> >> >> >> >> >> >> Thanks >> >> >> >> -Brad >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> osg-users mailing list >> >> osg-users@lists.openscenegraph.org >> >> >> >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> >> >> >> >> -- >> >> Ümit Uzun >> >> >> >> _______________________________________________ >> >> osg-users mailing list >> >> osg-users@lists.openscenegraph.org >> >> >> >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> >> > >> > >> > >> > -- >> > Ümit Uzun >> > >> > _______________________________________________ >> > 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 > > > > -- > Ümit Uzun > > _______________________________________________ > 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
