about a refcounting problem

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

about a refcounting problem

Théo de la Hogue
Hi Tim,
I've managed to find the reason why some TTObject instances was still alive after the deletion of a patcher.
the reason is not related to a bug of Foundation but more to a user case we maybe didn't figured out until now.

Many Modular TTObjects use to pass themself into a baton of a callback for directory observations.
For example in TTContainer class, when we bind on an address (in order to watch all the content below), we do :
mObserver = TTObject("callback");
baton = TTValue(TTObject(this), aContext);
mObserver.set(kTTSym_baton, baton);
mObserver.set(kTTSym_function, TTPtr(&TTContainerDirectoryCallback));


accessApplicationLocalDirectory->addObserverForNotifications(mAddress, mObserver); // ask for notification for addresses below

But the problem is that until now I used to remove the observation into the ~TTContainer function which was never called as there is still an instance refered by the observer baton …

A solution would be to call a method to clear this observation mechanism but this sounds not user friendly to have to call something before deleting things.
Another solution would be to register this as a pointer into the baton with the risk to have unconsistant refcounting.

What do you think ?
is this a typical case you already resolved by some magic tricks ?

Best,
TO


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|

Re: about a refcounting problem

Timothy Place
Hi Théo,

Did you ever do anything with regards to this pattern?  It is common in e.g. Max objects to detach from observing in an objects free method.  However it is also common that when you have attached to object to observe it that you also pay attention and get the "free" notification from that object so know to stop observing it.  Maybe this doesn't help, or maybe we need to make a change so this is all much easier?

Tim


On Fri, Jun 6, 2014 at 3:19 AM, Théo de la Hogue <[hidden email]> wrote:
Hi Tim,
I've managed to find the reason why some TTObject instances was still alive after the deletion of a patcher.
the reason is not related to a bug of Foundation but more to a user case we maybe didn't figured out until now.

Many Modular TTObjects use to pass themself into a baton of a callback for directory observations.
For example in TTContainer class, when we bind on an address (in order to watch all the content below), we do :
mObserver = TTObject("callback");
baton = TTValue(TTObject(this), aContext);
mObserver.set(kTTSym_baton, baton);
mObserver.set(kTTSym_function, TTPtr(&TTContainerDirectoryCallback));


accessApplicationLocalDirectory->addObserverForNotifications(mAddress, mObserver); // ask for notification for addresses below

But the problem is that until now I used to remove the observation into the ~TTContainer function which was never called as there is still an instance refered by the observer baton …

A solution would be to call a method to clear this observation mechanism but this sounds not user friendly to have to call something before deleting things.
Another solution would be to register this as a pointer into the baton with the risk to have unconsistant refcounting.

What do you think ?
is this a typical case you already resolved by some magic tricks ?

Best,
TO


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel



------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|

Re: about a refcounting problem

Théo de la Hogue-2
Hi Tim,
not sure if there is a solution to this problem … maybe it's like a dog chasing its tail as, if I understand well, the free notification will be sent when no more instance is referenced but there is still one reference stored into the observer that the object manage itself … so the only solution I've found is to have a way to clear observers myself before.

maybe we can introduce the notion of "main" instance so that when the TTObject handling the "main" instance is deleted it tells the other TTObjects refering to none "main" instances to forget … but it sounds like opening hell doors no ?

Best,
TO

Le 17 oct. 2014 à 23:24, Timothy Place <[hidden email]> a écrit :

Hi Théo,

Did you ever do anything with regards to this pattern?  It is common in e.g. Max objects to detach from observing in an objects free method.  However it is also common that when you have attached to object to observe it that you also pay attention and get the "free" notification from that object so know to stop observing it.  Maybe this doesn't help, or maybe we need to make a change so this is all much easier?

Tim


On Fri, Jun 6, 2014 at 3:19 AM, Théo de la Hogue <[hidden email]> wrote:
Hi Tim,
I've managed to find the reason why some TTObject instances was still alive after the deletion of a patcher.
the reason is not related to a bug of Foundation but more to a user case we maybe didn't figured out until now.

Many Modular TTObjects use to pass themself into a baton of a callback for directory observations.
For example in TTContainer class, when we bind on an address (in order to watch all the content below), we do :
mObserver = TTObject("callback");
baton = TTValue(TTObject(this), aContext);
mObserver.set(kTTSym_baton, baton);
mObserver.set(kTTSym_function, TTPtr(&TTContainerDirectoryCallback));

accessApplicationLocalDirectory->addObserverForNotifications(mAddress, mObserver); // ask for notification for addresses below

But the problem is that until now I used to remove the observation into the ~TTContainer function which was never called as there is still an instance refered by the observer baton …

A solution would be to call a method to clear this observation mechanism but this sounds not user friendly to have to call something before deleting things.
Another solution would be to register this as a pointer into the baton with the risk to have unconsistant refcounting.

What do you think ?
is this a typical case you already resolved by some magic tricks ?

Best,
TO


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel


------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
tap
Reply | Threaded
Open this post in threaded view
|

Re: about a refcounting problem

tap
Bonjour...

This seems like a pretty important issue to get straight.  Before trying to put a bandage on it I'd like to make certain we understand it thoroughly and have that documented.  I think the best way to do this is have unit tests for all of the refcounting scenarios we envisage ourselves using.  I think there is a basic one already which seems to pass.  So we can extend that.

Beyond that I'm probably going to need a picture with arrows showing the flow of events going on.  Might be something we can create using some web app during a Skype call?

Do we have a ticket number for this issue yet?

Tim


On Fri, Dec 12, 2014 at 8:19 AM, Théo de la Hogue <[hidden email]> wrote:
Hi Tim,
not sure if there is a solution to this problem … maybe it's like a dog chasing its tail as, if I understand well, the free notification will be sent when no more instance is referenced but there is still one reference stored into the observer that the object manage itself … so the only solution I've found is to have a way to clear observers myself before.

maybe we can introduce the notion of "main" instance so that when the TTObject handling the "main" instance is deleted it tells the other TTObjects refering to none "main" instances to forget … but it sounds like opening hell doors no ?

Best,
TO

Le 17 oct. 2014 à 23:24, Timothy Place <[hidden email]> a écrit :

Hi Théo,

Did you ever do anything with regards to this pattern?  It is common in e.g. Max objects to detach from observing in an objects free method.  However it is also common that when you have attached to object to observe it that you also pay attention and get the "free" notification from that object so know to stop observing it.  Maybe this doesn't help, or maybe we need to make a change so this is all much easier?

Tim


On Fri, Jun 6, 2014 at 3:19 AM, Théo de la Hogue <[hidden email]> wrote:
Hi Tim,
I've managed to find the reason why some TTObject instances was still alive after the deletion of a patcher.
the reason is not related to a bug of Foundation but more to a user case we maybe didn't figured out until now.

Many Modular TTObjects use to pass themself into a baton of a callback for directory observations.
For example in TTContainer class, when we bind on an address (in order to watch all the content below), we do :
mObserver = TTObject("callback");
baton = TTValue(TTObject(this), aContext);
mObserver.set(kTTSym_baton, baton);
mObserver.set(kTTSym_function, TTPtr(&TTContainerDirectoryCallback));

accessApplicationLocalDirectory->addObserverForNotifications(mAddress, mObserver); // ask for notification for addresses below

But the problem is that until now I used to remove the observation into the ~TTContainer function which was never called as there is still an instance refered by the observer baton …

A solution would be to call a method to clear this observation mechanism but this sounds not user friendly to have to call something before deleting things.
Another solution would be to register this as a pointer into the baton with the risk to have unconsistant refcounting.

What do you think ?
is this a typical case you already resolved by some magic tricks ?

Best,
TO


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel


------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel



------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|

Re: about a refcounting problem

Théo de la Hogue-2
Hi Tim,

Le 12 déc. 2014 à 16:59, Timothy Place <[hidden email]> a écrit :

Bonjour...

This seems like a pretty important issue to get straight.  Before trying to put a bandage on it I'd like to make certain we understand it thoroughly and have that documented.  I think the best way to do this is have unit tests for all of the refcounting scenarios we envisage ourselves using.  I think there is a basic one already which seems to pass.  So we can extend that.

Beyond that I'm probably going to need a picture with arrows showing the flow of events going on.  Might be something we can create using some web app during a Skype call?
I don't know about such web app … but I can prepare some pictures.


Do we have a ticket number for this issue yet?
now we have : https://github.com/jamoma/JamomaCore/issues/322

Best,
TO


Tim


On Fri, Dec 12, 2014 at 8:19 AM, Théo de la Hogue <[hidden email]> wrote:
Hi Tim,
not sure if there is a solution to this problem … maybe it's like a dog chasing its tail as, if I understand well, the free notification will be sent when no more instance is referenced but there is still one reference stored into the observer that the object manage itself … so the only solution I've found is to have a way to clear observers myself before.

maybe we can introduce the notion of "main" instance so that when the TTObject handling the "main" instance is deleted it tells the other TTObjects refering to none "main" instances to forget … but it sounds like opening hell doors no ?

Best,
TO

Le 17 oct. 2014 à 23:24, Timothy Place <[hidden email]> a écrit :

Hi Théo,

Did you ever do anything with regards to this pattern?  It is common in e.g. Max objects to detach from observing in an objects free method.  However it is also common that when you have attached to object to observe it that you also pay attention and get the "free" notification from that object so know to stop observing it.  Maybe this doesn't help, or maybe we need to make a change so this is all much easier?

Tim


On Fri, Jun 6, 2014 at 3:19 AM, Théo de la Hogue <[hidden email]> wrote:
Hi Tim,
I've managed to find the reason why some TTObject instances was still alive after the deletion of a patcher.
the reason is not related to a bug of Foundation but more to a user case we maybe didn't figured out until now.

Many Modular TTObjects use to pass themself into a baton of a callback for directory observations.
For example in TTContainer class, when we bind on an address (in order to watch all the content below), we do :
mObserver = TTObject("callback");
baton = TTValue(TTObject(this), aContext);
mObserver.set(kTTSym_baton, baton);
mObserver.set(kTTSym_function, TTPtr(&TTContainerDirectoryCallback));

accessApplicationLocalDirectory->addObserverForNotifications(mAddress, mObserver); // ask for notification for addresses below

But the problem is that until now I used to remove the observation into the ~TTContainer function which was never called as there is still an instance refered by the observer baton …

A solution would be to call a method to clear this observation mechanism but this sounds not user friendly to have to call something before deleting things.
Another solution would be to register this as a pointer into the baton with the risk to have unconsistant refcounting.

What do you think ?
is this a typical case you already resolved by some magic tricks ?

Best,
TO


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel


------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel