ViewerBase::stopThreading() includes this block of code:
for(Cameras::iterator camItr = cameras.begin();
camItr != cameras.end();
++camItr)
{
osg::Camera* camera = *camItr;
Renderer* renderer =
dynamic_cast(camera->getRenderer());
if (renderer)
{
HI Cory,
The Done flag is a hint to say tell threads that work should stop, so
once it's stopped you want to reset things so that we you start the
threads again it doesn't think that it's done again.
Robert.
On Mon, Jun 15, 2009 at 9:37 PM, Cory Riddell wrote:
> ViewerBase::stopThreading() inclu
Hi Robert,
The reason I started to look at this flag is because I'm getting
frequent access violations when shutting down my app.
Usually, the problem is in GraphicsContext::runOperations().
When I shut down, I call setDone(true) on my viewer instance. I also
call stopThreading() and make s
Hi Cory,
Do you find that normal OSG apps have problems when shutting down?
Which version of the OSG are you using?
When you say delete, exactly how are you going about delete? Could
you supply an example of the clean up code you are using, it does
sound like there is something amiss.
Robert.
Hi Robert,
I just saw your post about the release of 2.9.5 and it includes
threading fixes. I think I'll grab that and give it a go before I
bother the list about this any more.
Thanks,
Cory
Robert Osfield wrote:
Hi Cory,
Do you find that normal OSG apps have problems when shutting down?
Robert et al,
So, the 2.9.5 build doesn't fix my problem.
My app has two threads. The second one is my viewer thread. To
shutdown, my main threads calls viewer->setDone(true) then waits on
a shared lock. The viewer thread stops running (I start the viewer with
viewer->run()) and then calls vi
Hi Cory,
Could you modify one of the OSG examples to reproduce the problem you
are seeing so that others can have a bash at reproducing the problem
as trying to debug this type of stuff remotely is next to impossible.
Robert.
On Tue, Jun 23, 2009 at 10:45 PM, Cory Riddell wrote:
> Robert et al,
You know, I keep coming back to the done flag. It isn't volatile and I
don't see the mechanism that keeps the value synchronized between
threads. I know there has to be something that does it, because nobody
else is seeing thread related shut down problems.
Perhaps that's my first problem: as
Hi Cory,
Try changing the flag to volatile and see what happens.
Robert.
On Thu, Jun 25, 2009 at 3:39 PM, Cory Riddell wrote:
> You know, I keep coming back to the done flag. It isn't volatile and I don't
> see the mechanism that keeps the value synchronized between threads. I know
> there has t
Cory,
FWIW, I do what you do : I have an OpenThreads::Thread class which _has_ a
viewer. The parent application starts this thread up, and lets it get on
with viewer creation, frame dispatch, viewer deletion and so on.
I had very similar problems to you a while ago (> 1 year? ) when I
originally
David,
Thanks for the information. It sounds like there might actually be a
problem here. Rather than code around it, I'm going to keep poking
around to see if I can figure out what's going on. It's nice to have a
plan B though, so thank you for the advice.
Right now it looks like the Viewer:
David & Robert,
I think I found the race that is giving me problems.
When I close my app, sometimes GraphicsWindowWin32 gets the WM_DESTROY
message before I call viewer->setDone(). In these cases, the
GraphicsWindowWin32 gets destroyed (marked invalid), but I think the
graphics thread remain
I'm quite confident this is my problem. I added a handler for
WM_DESTROY that sleeps my main thread for 1000 ms. This is enough time
for the second thread to process the message, marking the
GraphicsWindowWin32 instance as invalid which prevents the viewer from
closing the context (invalid cont
13 matches
Mail list logo
