Hi, On Thu, 2007-10-25 at 08:54 -0500, Carsten Neumann wrote: > 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.
Not quite, the goal was to simplify things, not per se getting rid of something. So IMHO if 'getting rid' of something does not work towards the goal something should be changed. > 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. where did the auto ptr go ? > 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 ? Hmm, but in order to do this you record, transmit and apply ref count operations to the remote aspect (or has this changed, the code looks still the same ?). As you do it only for a limited set of objects/calls I still would call it an optimisation ;-). Because it should work if you do it for all objects/calls. > > Especially as the optimisation part causes all this internalptr stuff to > > come up in user space. > > Yes, personally I find this very ugly. Good so I'm not alone ;-). Maybe we should take a step back and see if we can find a nicer user space solution ;-) Maybe we should really start from the user interface and work our way towards the core ;-) > 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. But than why not put the ref counting into fields instead of pointer classes. This way we get this part out of the normal class code (which AFAIK is the goal). And if you want to put the parent handling into the fields to you blow them up anyway. If you want to force the user to use ref ptrs you can still do so by returning a kind of auto ptrs from everything , the class interface and the fields. This currently is the solution I tend to find the best compromise. And it gives you more options to optimise internally without sacrificing a clean user interface. kind regards, gerrit ------------------------------------------------------------------------- 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
