Hi Gerrit,
Gerrit Voß wrote:
>
> Ah ok, I change the order back so that that one works again.
We thought about doing that but couldn't find a way with the atomic
operations that did not need an additional lock to avoid races.
How are you doing it?
> I don't like the weak ptrs are always MT ptrs setup. I don't have a
> problem with jumping through the aspect store but the logic should stay
> the same.
I was thinking about just getting rid of the normal WeakPtrs and only
have MTWeakPtr. That way at least it's clear what they do.
What do you see as the problem of making all Weak's MT?
> Let me change things back to the original order/sequence and think about
> it, you can't switch to the aspect store that easy because nothing
> inside OpenSG really stores a weak ptr object and before we start to
> mess around with it I want to be sure we absolutely have to ;)
Not sure I'm following here... Beacons are Weakptrs, and AFAIU we always
have an AspectStore for each FC anyway.
Carsten Neumann wrote:
>
> it was problematic for the regular ref count, because it would become
> hard to tell when an aspect copy is not needed anymore. Also, going to
> the AspectStore for every ref count change seems expensive - weak ref
> counts are much less common of course.
Yup.
> hm, I think we would have to keep the aspect the weak pointer belongs to
> in the pointer object.
Not sure if that's really a problem. I can't quite think of a good
reason to keep pointers to a different aspect's copy around. it sounds
very confusing.
The main reason for getting rid of our mandatory MTPtrs was to simplify
and speed up the code and to make things easier for users.
> agreed. I started looking into the implementation, the WeakRefCountPtr<>
> template is not hard to write, but the fields looked to be more painful,
> since they would not store something convertible to FieldContainer *.
Don't we have that problem already anyway? The current WeakPtrs need to
go through a RefPtr too, no?
Yours
Dirk
------------------------------------------------------------------------------
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
