Hi, On Sat, 2007-09-15 at 17:44 -0500, Carsten Neumann wrote: > Hi, > > > maybe it is best if I start with a description of how things are done on > the trunk at the moment (at least the way I read the code ;) ): > - pointer fields store C ptrs > - the interface in the <FCName>Base classes does not grant access to > pointer fields, but they can be modified either through a set of > functions or through the GetFieldHandle/EditFieldHandle classes returned > by the generic interface.
> The reference count is maintained by explicit calls to addRef/subRef > inside these generated functions and since there is no "legal" way to > bypass these (well, there is const_cast ...) it is much harder to break > things than in OpenSG 1. > > Now, instead of managing the ref count in the access functions we could > just store smart pointers that do the ref counting in the c'tors and > assignment operators. > One problem that we have to deal with then are > circles in the pointed to chains, which for OpenSG are introduced only > (?) through parent pointers, e.g. in NodeCore. These pointers would > become weak pointers (which modify a separate weak ref count in each > field container [1]). Not quite, there are at least the beacons which should be weak too. > [1] The reason for the separate weak ref count is to have a way to tell > if a weak ptr still points to a "live" object. A pointed to field > container would not be deleted until both weak and regular ref count > become less or equal zero. In order to prevent the circular references > problem, (pointer) fields would be emptied as soon as the regular ref > count becomes less or equal zero. Why do you need to change the behaviour of weak ptr ?. AFAIK the common (boost) understanding a weak pointer is merely an indirection. And a weak pointer should never keep the underlying object alive. Is it really wise to have yet another OpenSG special interpretation ? Wouldn't it be easier to have the weak pointer use the aspect store as the binary blob and by storing the aspect it should be straight forward to implement the correct behaviour ?. I probably give it a short try for the current version as we need it anyway. > [2] Locally this works because there is always the source aspect > available to copy/share data from/with. But since only changes to an > objects contents are transmitted the remote side would not receive a new > copy of data. Introducing a back-channel on which the RemoteAspect can > request a retransmit of the data unfortunately defeats the idea of being > able to run the cluster with broadcasts. > > [3] Well, not quite impossible, but the ref pointers would need to have > an interface that allows to modify the pointer they store internally > without affecting the pointed to objects ref count. However, this > somewhat defeats the whole idea of ref pointers. I actually would not have a big problem with this. The whole syncing is quite low level and well hidden so it should be ok, and we know it works, well as long as I did not do some of these optimistic approximations like in the setFCPtrForAspect case. kind regards, gerrit ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
