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

2009-06-29 Thread Cory Riddell
I was using the Windows close button in the title bar or alt-f4. It does not happen with osgwindow because (as far as I can see), it closes down via a different route. In that example, osgwindow gets a WM_CLOSE message which is handled by the event handler as a CLOSE_WINDOW message and

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

2009-06-28 Thread Robert Osfield
Hi Cory, How did you close the application? Pressing escape or closing it via the window close button? Does the problem happen with other examples, such as osgwindow? Robert. On Fri, Jun 26, 2009 at 9:28 PM, Cory Riddellc...@codeware.com wrote: In another message thread I've been talking

[osg-users] race condition in GraphicsWindowWin32?

2009-06-26 Thread Cory Riddell
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

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

2009-06-26 Thread Cory Riddell
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