Hi Gerrit,
Gerrit Voss wrote:
> On Thu, 2007-10-25 at 04:01 -0500, Dirk Reiners wrote:
>> Well, my main idea in suggesting that was to simplify things
>
> Hmm, my current feeling is that right now, with the ref ptrs as they
> are, we are heading in the opposite direction anyway.
>
> I'm still a little bit confused why you choose to do two different
> things at once, classic ref ptrs and changelist optimisations.
well, the goal was to get rid of any form of "manual" ref counting which
included removing it from generated code. The three ref counts
(internal, external, weak) are a side effect of this as one looses
explicit control over the ref count when it is handled by the pointers.
One example of this is that right now the RemoteAspect can populate
pointer fields without touching the pointed-to object's ref count and
then later adjusts the ref count when it interprets the addRef/subRef
messages. This is not possible if the pointer fields store pointers that
handle the ref count.
Now consider the consider the following: A user creates a scenes which
is kept alive by ref pointers from her application. Since addRef/subRef
events are not transmitted over the cluster, what keeps the scene alive
on the remote side - or when can the remote side fully destroy an object
and be sure it is not reference by the app anymore ?
This is the reason for the distinction between internal and external ref
count and also why only external ref count changes are recorded - which
I assume you are referring to as "changelist optimisation" above ?
> Especially as the optimisation part causes all this internalptr stuff to
> come up in user space.
Yes, personally I find this very ugly. I guess it could be hidden a bit
more by having the respective MFields return proxy objects instead of
references from operator[] - for MF<FOO>ParentPtr this is of course a
must, if they are exposed for write access, it's on my TODO.
> I kind of still doubt that the ref ptr infrastructure really is the best
> place to do this.
>
>> and get rid of the whole FB hierarchy
>
> let me think about it a little bit.
please, share any thoughts or ideas you have with us :)
Thanks,
Carsten
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
