From: Gerrit V. <vo...@ca...> - 2009-03-27 04:13:29
|
Hi, On Thu, 2009-03-26 at 22:41 -0500, Dirk Reiners wrote: > 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? lock it ;). You can run a simple unfair xor spinlock without adding additional mem to the containers and as long as it is only there to guard a few simple operations I don't see a big performance issue, especially as the pattern does not look like it would be a highly contested one. > > 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? it does not easily work with our current field implementation. And it's not symmetric but that is more a style issue ;) > > 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: > > > > 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? > here you lost me a little. WeakPtrs go through RefPtr in a sense that we don't have an explicit class and handle the differences through policies. But I don't see the problem we already should have ;) kind regards, gerrit |