Hi, On Wed, 2010-04-28 at 23:18 -0500, Carsten Neumann wrote: > Hello Gerrit, > > Gerrit Voß wrote: > > On Thu, 2010-04-29 at 10:44 +0800, Gerrit Voß wrote: > >> On Thu, 2010-04-29 at 08:12 +0800, Gerrit Voß wrote: > >>> On Wed, 2010-04-28 at 17:40 -0500, [email protected] > >>> wrote: > >>>> Author: cneumann > >>>> Date: Wed Apr 28 17:40:32 2010 > >>>> New Revision: 2406 > >>>> Trac changeset: http://www.opensg.org//changeset/2406 > >>>> > >>>> Modified: > >>>> trunk/Source/System/Dynamics/Base/OSGFrameHandler.cpp > >>>> trunk/Source/System/Dynamics/Base/OSGFrameHandler.h > >>>> trunk/Source/System/Dynamics/Base/OSGFrameTaskMixin.h > >>>> trunk/Source/System/Dynamics/Base/OSGFrameTaskMixin.inl > >>>> Log: > >>>> fixed: register FrameTasks with the correct aspect copy of the > >>>> FrameHandler > >>> ?? there is only one copy of the FrameHandler. Is this really working, > >>> my current guess would be that FrameHandler::the() will return NULL for > >>> all but the creating aspect if setup this way. > >> arrrg, one should not guess before the first coffee in the morning ;). > >> > >> As it is a singleton you will constantly override the FrameHandler if > >> you continuously call get from different aspects. > >> > >> It was not meant to be MT save for more than the standard app thread > >> aspect 0 and drawers parallel with different aspects. What is the > >> app model you have in mind ? > > > > ok, I think I understand what you tried to fix, the multiple addition of > > tasks during the tasks sync. > > yes, I wanted them to be registered with the FrameHandler copy for their > aspect. > > > Hmm, this does not seem to work correctly > > this way as it breaks my existing par draw apps ;(. I'll throw it around > > my head and see what falls out ;) > > oops, sorry, I had hoped just doing the registration with the correct > copy of the FrameHandler would be safe. Do you already have some more > details in which way it breaks?
the FrameHandler was designed to be a global instance, e.g. it does not sync (neither cluster nor threads). So in the second aspect the MTRefPtr will report NULL and consequently the program will create a new one and assign it to the global instance ptr, overriding the original one, the original aspect in turn will to the same, so in the worst cast you ping pong FrameHandler creations between the different threads/aspects. At the minimum you loose the task registered initially in the first thread (this is what happens to my app right now). E.g. you can actually test it, there is a CSM example, Examples/CSM/SimpleAnim-Par using a parallel drawer with a simple animation. Currently the animation does not work any more as the app thread tasks have disappeared during the sync. My current 'quick' solution would be to forbid a taks to be registered twice. But I'm still thinking if this would be to restrictive. Preferable I would forbid the registration during the creation of the aspect copy, still looking at this ;) Making all tasks not syncing might be to extreme ;) kind regards gerrit ------------------------------------------------------------------------------ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
