Hi Gerrit,
Gerrit Voss wrote:
> On Thu, 2007-10-25 at 08:54 -0500, Carsten Neumann wrote:
>> Gerrit Voss wrote:
>>> 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.
yes, simpler is THE thing all this ref counting pointers in fields does
not achieve. Unfortunately I see no way to hide the different pointer
types as long as there are functions that return a pointer or reference
to the actual field. One can only pretend up to a certain point that a
std::vector<ReferenceCountPointer<Node,
InternalRefCountPolicy<FieldContainer>, FieldContainer> > is the same
thing as a std::vector<FieldContainer *> even after resorting to
hair-raising stunts involving reinterpret_cast -- which I'm convinced
will cause some pain by gcc 4.4 at the latest, but that's a different story.
>> 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 ?
Sorry, I'm not following you here, which auto ptr and how does it fit
into the picture ?
>> 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.
No, doing it for internal/weak pointers will at least produce wrong ref
count values on the remote side: As soon as a pointer field is populated
on the remote side the respective ref count of the pointed to object is
adjusted (that's what the pointers stored in the field do), applying the
adjustments from the transmitted changelist on top of this screws up the
values.
>>> 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 ;-)
Ok, but I'm not the one you have to argue with ;)
>> 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.
The problem with that are the usual suspects operator[], front(), back()
which return a reference.
Anyway, putting the parent handling into the fields would be nice as it
would allow write access to them, however I'm still thinking about how
to do it, as I believe I need to know the exact type of the container in
which the field is contained -- Pointer fields are currently partial
specializations of MField, which means I can not add an arbitrary
additional template parameter that provides this information.
> 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.
I believe the "getting the user to use ref ptrs" part is better achieved
by consistently using them in examples and test programs and also
utilities like the SimpleSceneManager, well basically everywhere except
maybe the RenderTraversalAction ;)
This way we don't have to take any form of performance penalty for
passing around anything different from a C ptr.
> And it gives you more options to optimise internally without sacrificing
> a clean user interface.
Do you have thought this through to the end? Could you provide some more
details, please? (I know it is tedious and time consuming to write these
things in mails, but I'd really like to find a nicer solution than what
I'm heading for right now, so please share your thoughts)
On the progress report side:
- the last compile errors I get come from the FileIO library, most seem
easy to fix by replacing SFNodePtr::iterator with
Node::ChildrenFieldType::iterator or similar things.
- one thing seems a bit more tricky though: The new osb loader uses the
following:
if(fieldType.getContentType().isDerivedFrom(
FieldTraits<FieldContainerPtr>::getType()) == true)
Now, with the whole zoo of pointer types this simple check does not
quite cut it anymore. Of course I could check
FieldTraits<FieldContainerInternalRefPtr>,
FieldTraits<FieldContainerWeakRefPtr> and
FieldTraits<FieldContainerParentPtr> but that is a bit more verbose ;)
Should I teach our type system about pointer types or do you have a
better idea how to do this (I'm not so excited about tentatively casting
the field handle as is done, e.g. in the GraphOps) ?
- there's a load of linker errors that probably are related to not
including the respective .inl from the .h in new files, I'll tackle them
over the weekend.
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
