Hi, On Tue, 2010-12-14 at 20:49 +0100, Sebastian Till wrote: > > ok, but there should also be a "Refcount decreased" entry in A's > > Changelist, which on the next sync should take care of destroying A's > > State object. > > I'd like to understand why that does not happen/work in this case, since > > this is the mechanism that also takes care of the more usual cases. > > There will be no "Refcount decreased" entry for A's StatePtr because Thread A > of > my application can't destroy the corresponding Material immediately since a > removal of it just results in a decreased RefCount (from 2 to 1) and an entry > to > the changelist. So, the material will be destroyed during a synchronisation > where the call Changelist::applyAndClear() will finally delete it. However, > this > applyAndClear call locks the current (Thread B's) Changelist to readonly! So > the > StatePtrs of each aspect of the Material will decrease by one as explained in > my > previous mail but without adding these decreases to the changelist. > By the way, even if it would do that, I don't apply the changes made in > Thread B > to Thread A. (At least not yet.) > > > not putting the ref count changes into the changelist may be the right > > thing for State objects in Material, but if there are other places it is > > used the situation might be different. > > I used the xxxCacheRefCP calls for those CachePtrs only and within the State > class itself. This State class is the only part I am not sure about. Where > reside StatePtrs and access to methods of them in OpenSG? Is there any > situation > in which the aspects of a state will be synchronised? I might should remove > the > xxxCacheRefCP functions from the State class and ensure proper beginEditCP and > endEditCP calls instead to enforce the synchronisation of those aspects but I > would prefer not to since one of the aspects will never be used. > > > hm, one thing that depends much more on the changelist than multiple > > threads on one machine is the cluster code, so there is a possibility it > > is broken with the changes. > > I see but shouldn't the memory leaks then also affect the cluster code?
in general this agrees with what I found so far. The problem is I do not have a good solution. Well in a sense I have, but it is OpenSG 2.x. So the problem is that the 'real' fix is quite complex and I do not see an easy way to backport something. So if we can safely modify the internal refcounting for this case I would go for it as a workaround. kind regards gerrit ------------------------------------------------------------------------------ Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
