Releasing a NODE | developer.brewmp.com Releasing a NODE | developer.brewmp.com

Developer

Releasing a NODE

Hi Brewers,
Does anyone have an idea why the IVFSNODE_Release returns a -1 value when releasing a node. Does this mean that the node was not properly released?

thanks....

whreckz09 wrote:Hi Brewers,
Does anyone have an idea why the IVFSNODE_Release returns a -1 value when releasing a node. Does this mean that the node was not properly released?
thanks....
I have the same problem except that mine returns 1. What does this mean?
Mike.

whreckz09 wrote:Hi Brewers,
Does anyone have an idea why the IVFSNODE_Release returns a -1 value when releasing a node. Does this mean that the node was not properly released?
thanks....
I have the same problem except that mine returns 1. What does this mean?
Mike.

Hi,
Any release function in BREW including the IVFSNode_Release returns the current referance count of the object. So If you are having 1 returned then the object has not been destroyed. This is may not be wrong, it depends on if the pointer to the object you released was the last referance or not.
-1 would be bad. It should return a uint32 and 0 would mean the object was destroyed. -1 implies you just released an object that was already destroyed. It also implies something returned the wrong type.
Referance counting in the Vfs tree is a bit tricky, in fact very easy to get wrong. If you are having problems with nodes not releasing post the code that created the node and I will take a look at it to see if I can spot what is wrong. Its usually that there has been a call to IVFSCONTAINER_AddChild without a subsequent release call on the node.
James

Hi,
Any release function in BREW including the IVFSNode_Release returns the current referance count of the object. So If you are having 1 returned then the object has not been destroyed. This is may not be wrong, it depends on if the pointer to the object you released was the last referance or not.
-1 would be bad. It should return a uint32 and 0 would mean the object was destroyed. -1 implies you just released an object that was already destroyed. It also implies something returned the wrong type.
Referance counting in the Vfs tree is a bit tricky, in fact very easy to get wrong. If you are having problems with nodes not releasing post the code that created the node and I will take a look at it to see if I can spot what is wrong. Its usually that there has been a call to IVFSCONTAINER_AddChild without a subsequent release call on the node.
James

MikeH wrote:I have the same problem except that mine returns 1. What does this mean?
Mike.
Here is my code:
nerr = IACTORCONTEXT_CreateString(this->getActorContext(),L"test",100,this->getActorVfsNode(),0,&node);
nerr = IVFSSTRUCTCONTAINER_AddChild((IVfsStructContainer*)this->getActorVfsNode(),node);
nerr = IVFSNODE_Release(node);
After I release the node the value of nerr is 1.
Thanks,
Mike.

MikeH wrote:I have the same problem except that mine returns 1. What does this mean?
Mike.
Here is my code:
nerr = IACTORCONTEXT_CreateString(this->getActorContext(),L"test",100,this->getActorVfsNode(),0,&node);
nerr = IVFSSTRUCTCONTAINER_AddChild((IVfsStructContainer*)this->getActorVfsNode(),node);
nerr = IVFSNODE_Release(node);
After I release the node the value of nerr is 1.
Thanks,
Mike.

Hi,
Yes that is exactly as it should be. With one mistake; the return value of IVFSNODE_Release is not an error code but in fact the referance count of the node.
The call to IACTORCONTEXT_CreateString creates a node with a ref count of 1. The call to VFSSTRUCTCONTAINER_AddChild adds that node to the vfs tree and addref's it to 2. The call to release frees up the local refereance to the node taking it back to 1 (and returning 1).
At this point you do not want the node to be destroyed as the structcontainer you added it to with VFSSTRUCTCONTAINER_AddChild owns the node and still wants to access it. When the structcontainer with that this call got (this->getActorVfsNode()) is released it will subsequently release its referance to the node causeing the ref count to go to 0 and then the node to be destroyed.
A common problem I find in actors is not having the call to release after the call to addchild. If this mistake is made the ref count will be 2 and then the node will not be released when the structcontainer is released as the ref count of the node will only drop to 1 not to 0. This would result in a memory leak.
In your case everything looks good, except that you are expecting IVFSNODE_Release to give you an error code. Just ignore the return code of this call unless you are trying to debug a memory leak...
Thanks
James

Hi,
Yes that is exactly as it should be. With one mistake; the return value of IVFSNODE_Release is not an error code but in fact the referance count of the node.
The call to IACTORCONTEXT_CreateString creates a node with a ref count of 1. The call to VFSSTRUCTCONTAINER_AddChild adds that node to the vfs tree and addref's it to 2. The call to release frees up the local refereance to the node taking it back to 1 (and returning 1).
At this point you do not want the node to be destroyed as the structcontainer you added it to with VFSSTRUCTCONTAINER_AddChild owns the node and still wants to access it. When the structcontainer with that this call got (this->getActorVfsNode()) is released it will subsequently release its referance to the node causeing the ref count to go to 0 and then the node to be destroyed.
A common problem I find in actors is not having the call to release after the call to addchild. If this mistake is made the ref count will be 2 and then the node will not be released when the structcontainer is released as the ref count of the node will only drop to 1 not to 0. This would result in a memory leak.
In your case everything looks good, except that you are expecting IVFSNODE_Release to give you an error code. Just ignore the return code of this call unless you are trying to debug a memory leak...
Thanks
James

Awesome, Thanks so much for you help James.
MikeH.

Awesome, Thanks so much for you help James.
MikeH.