Hello Christoph,
Christoph Schäfer wrote:
> Carsten Neumann schrieb:
>> Anyways, I don't think that should be a problem. However, I'm wondering
>> if your program remains responsive or if one if the threads just gets
>> stuck in the barriers. The way I could imagine this to happen is that if
>> thread A never sees the change of the m_syncForRenderingNeeded variable.
> The app keeps responsive, I even can load other .osb files after the
> first one and will see the correct structure of the model in the gui's
> scene graph. What I've noticed right now: I can't load .wrl files
> anymore. .osb will work but on loading a vrml the rendering crashes..
> maybe this might be a pointer to the problem?
> 0-Pointer error at line 240 in
> c:\ft1cs\libs\opensg2_vc80\source\system\nodecores\drawables\base\osgdrawablestatsattachmentbase.inl
>
> (svn r1680)
[SNIP - backtrace]
hm, I don't think it is directly related to your problem, but I fixed
that bug (cf. r1682).
>> Using a variable in this way to communicate between threads sometimes
>> has strange effects. A popular (although from what I understand not 100%
>> correct way) is to make the variable volatile (or at least the reads
>> from it).
>>
> I tried it with volatile, which seems to be the better choice for
> variables like this one anyway. That didn't solve the problem though.
> From what I can see in the Visual Studio debugger and how the app
> behaves I think the syncing is working but there is a problem with the
> renderaction probably?
One other thing you might want to double check: pointers are normally
only valid for the aspect they were created in, so you can not pass
around pointers between threads on different aspects and they
automatically point to the right aspect copy. If you need this kind of
behaviour, use MTRefPtr, they can be dereferenced from every aspect [1]
and will point to the right aspect copy of the pointed-to container.
Hope it helps,
Carsten
[1] The small catch here is that there must have been at least one sync
from the aspect the object was created in to the current aspect before
the MTRefPtr can point to something meaningful.
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
