Re: [osg-users] race condition in GraphicsWindowWin32?

Fri, 26 Jun 2009 14:02:52 -0700

Putting a call to setGraphicsThread(0) near the top of GraphicsWindowWin32::destroyWindow() prevents the problem. Does this seem like a hack, or should I submit a patch?

Is there any reason why a graphics thread should still be running after a graphics window has been destroyed?

Cory

Cory Riddell wrote: 
In another message thread I've been talking about a threading problem in
my app. I just figured out how to reproduce it with one of the samples,
so I thought I would post that here in hopes that somebody else would
have an idea on how to fix this.

I think it's a shutdown sequence race. To reproduce the problem, start
the osgviewerMFC sample app. Load the cow, turn on stats (hit 's') then
close the app. Sometimes you will get a crash. To make the crash happen
all the time, add a Sleep() call to the start of the WM_DESTROY handler
in MFC_OSG_MDIView.cpp:
  
void CMFC_OSG_MDIView::OnDestroy()
{
    Sleep(1200);
    if(mOSG != 0) delete mOSG;

    WaitForSingleObject(mThreadHandle, 1000);

    CView::OnDestroy();
}
    

As far as I can see, when GraphicsWindowWin32 process the WM_DESTROY
message, it sets _valid to false for the context. This prevents
~Viewer() from closing the context. This leaves a thread running and
that generates an access violation because it tires to use elements that
have been deleted. If the Viewer destructor is processed first, then
everything is ok.

This is related to the presence of a slave camera (that's why you have
to turn the stats display on).

Any ideas?

Thanks,
Cory
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

  
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Reply via email to