Re: [Opensg-core] AttachmentContainer ref counting

[Carsten N. <car...@gm...>]

	Hello Gerrit,

Gerrit Voß wrote:
> On Wed, 2010-08-18 at 19:46 -0500, Carsten Neumann wrote:
>> On 18.08.2010 19:07, Gerrit Voß wrote:
>>> On Wed, 2010-08-18 at 16:07 -0500, Carsten Neumann wrote:
>>> short question, so I have the full picture, what was the reason behind
>>> r2472 because that one changed what was recorded and what was not ?
>> on the cave side in our app attachments were dying when 
>> RemoteAspect::receiveSync() cleared the newContainers vector at the end. 
> 
> ok, what kind of attachments were these ? All or only a variant 
> (MTLocal, Global) ? 

it was NameAttachments, they were all global.

>> The change in r2472 helped for that case and seemed to simply correct a 
>> mixup (it does not seem to make sense to use recorded ref count changes 
>> on the attachments if the AttachmentContainer itself is MTLocal).
> 
> hmm, MTLocal does not mean ClusterLocal but I guess in most cases we
> actually use the combination.

ok, but I thought MTLocal implies ClusterLocal, no? Otherwise it seems 
even more inconsistent, the container would exist locally in only one 
aspect, but still is sent over the network?

> I'll try to track down why I changed this,
> my current guess would be named local containers, because it looks like
> it was for containers which themselves have multiple aspects but the
> carrying one does not. 
> 
>> Having thought a bit more about this now I believe 
>> AttachmentContainer::_sfAttachments should behave like any other field, 
>> i.e. only make unrecorded changes - if that is not the correct behavior 
>> all other containers would have the same issue.
> 
> Not unlikely but sfAttachments is the field where local and non local
> combinations will be most likely mixed, so finding problems there is
> far more likely. It is also something most other containers just derive,
> independent of their own global/local nature so I expect special cases
> in there. I'm not sure if pushing them up to every single pointer field
> is necessary so I'm not so worried about having special cases in there
> for the time being.

hm, ok.

> My current plan would be to rebuild you aspect setup, somewhere in the
> changed/transmit pipleline something seems to get lost. Short question,
> is the server side one of the standard servers or a modified version ?

the server is in fact a VRJuggler program, that runs a separate thread 
to receive the CL and merges it to the juggler render thread in postFrame().
Let me back out r2472 and the AttCon change locally and give you more 
details on what happens.

	Cheers,
		Carsten